Remove unused capabilities feature and cleanup

COMMIT SUMMARY
--------------
Removes the entire capabilities feature (apt-install, packet-capture) that
was unused and not actively maintained. This simplifies the codebase and
removes unnecessary complexity around capability trust, helper processes,
and pod-based capture infrastructure.

CHANGES
-------
sloptrap (main script):
  - Removed SLOPTRAP_SUPPORTED_CAPABILITIES array
  - Removed --trust-capabilities CLI flag
  - Removed capability state path management functions
  - Removed capability trust validation functions
  - Removed packet capture helper infrastructure (pod creation, helperd)
  - Removed capability-enabled container special handling
  - Removed capability build stamp tracking
  - Simplified prepare_container_runtime() - removed capability logic
  - Simplified build_image/rebuild_image - removed capability trust checks
  - Simplified run_runtime_container_cmd - removed helper process management
  - Removed capability environment variables and flags
  - Simplified dispatch_target - removed --trust-capabilities handling

Dockerfile.sloptrap (new):
  - Added new embedded Dockerfile template
  - Removed capability helper binaries from image
  - Simplified entrypoint to just codex directly
  - Removed sloptrap-entrypoint, sloptrap-helperd, slop-apt, slopcap
  - Removed CAPABILITY_PACKAGES build argument
  - Simplified RUN instructions

tests/run_tests.sh:
  - Removed run_git_ignore_mask test (was testing capability trust)
  - Updated runtime_context_prompt test (removed --trust-capabilities)
  - Updated sh_reexec test (removed --trust-capabilities)
  - Updated resume_omits_runtime_context test (removed --trust-capabilities)

tests/capability_repo/.sloptrap (deleted):
  - Removed test manifest that required capabilities

tests/invalid_manifest_capabilities/.sloptrap (deleted):
  - Removed test manifest for capability validation

REASON
------
The capabilities feature was identified as unused and unnecessary.
Maintaining it added complexity without providing value. Removing it:
  - Reduces code complexity and maintenance burden
  - Eliminates capability trust state management
  - Removes helper process infrastructure
  - Simplifies container build and runtime logic
  - Removes pod-based capture infrastructure

VERIFICATION
------------
  - All 14 regression tests pass
  - shellcheck sloptrap passes with no warnings
  - No regressions in core functionality (ignore mounts, session management,
    network isolation, etc.)

BACKWARD COMPATIBILITY
----------------------
Breaking change: Any manifests with capabilities= entries will need to be
updated to remove the capabilities key. The --trust-capabilities flag is
no longer supported.

README.md

@@ -62,14 +62,11 @@ Supported keys when the manifest is present:
 | --- | --- | --- |
 | `name` | project directory name | Must match `^[A-Za-z0-9_.-]+$`. Used for image/container naming. |
 | `packages_extra` | *empty* | Additional Debian packages installed during `docker/podman build`. Tokens must be alphanumeric plus `+.-`. |
-| `capabilities` | *empty* | Optional privileged features. Supported values are `apt-install` and `packet-capture`. Capability-enabled runs require Podman. When `packet-capture` is combined with `allow_host_network=true`, sloptrap shows a runtime warning with concrete consequences and requires an interactive acknowledgement on every run. |
 | `allow_host_network` | `false` | `true` opts into `--network host`; keep `false` unless the project absolutely requires direct access to host-local services. |
 
 Values containing `$`, `` ` ``, or newlines are rejected to prevent command injection. Setting illegal keys or malformed values aborts the run before containers start.
 sloptrap always runs Codex with `--sandbox danger-full-access --ask-for-approval never`. `codex_args` is deprecated and rejected if present.
 
-Capability trust is local state, not part of the repository. Builds for manifests that request capabilities require either an interactive trust confirmation or `--trust-capabilities`. Once the current manifest is trusted, its requested capabilities are enabled automatically for that project configuration. The `allow_host_network=true` plus `packet-capture` combination still requires a separate interactive acknowledgement each time a runtime container is launched.
-
 ### `.sloptrapignore`
 
 - Parsed using gitignore-style globbing with support for `!negation`.
@@ -99,7 +96,7 @@ Behaviour:
 - Fresh interactive `run` sessions receive a launcher-generated startup prompt telling the agent it is inside sloptrap, summarising the resolved manifest/runtime state, and pointing it at `/workspace/.sloptrap` for exact project configuration. `resume` does not inject that prompt again.
 - Exit status mirrors the last target executed; errors in parsing or setup abort early with a message.
 
-`--print-config` fields include `manifest_present=true|false`, requested/enabled capability lists, trust status, resolved paths, and the sanitised ignore mount roots so you can confirm what will be hidden inside the container.
+`--print-config` fields include `manifest_present=true|false`, resolved paths, and the sanitised ignore mount roots so you can confirm what will be hidden inside the container.
 
 ### Regression Suite
 
@@ -125,20 +122,13 @@ Targets are supplied after the code directory. When omitted, sloptrap defaults t
 
 The launcher executes targets sequentially, so `./sloptrap repo build run` performs an explicit rebuild before invoking Codex. Extra targets may be added in the future; unknown names fail fast.
 
-### Capability Helpers
-
-When the current manifest's capabilities are trusted and enabled, the container includes helper commands:
-
-- `slop-apt install <package...>` for session-scoped package installation.
-- `slopcap capture --interface <iface> [--filter <expr>] [--output <path>] [--stdout]` for non-promiscuous packet capture through a dedicated helper container. Host-network captures require an explicit acknowledgement each run.
-
 ## Execution Environment
 
-- Container engine: Podman or Docker for standard runs. Capability-enabled runs require Podman. Podman uses `--userns=keep-id`; Docker receives the equivalent `--user UID:GID` for standard runs.
+- Container engine: Podman or Docker for standard runs. Podman uses `--userns=keep-id`; Docker receives the equivalent `--user UID:GID` for standard runs.
 - Filesystem view: the project directory mounts at `/workspace`; `${HOME}/.codex/sloptrap/state/<project-hash>` mounts at `/codex`; `${HOME}/.codex/auth.json` mounts at `/codex/auth.json`.
 - Ignore filter: `.sloptrapignore` entries are overlaid with tmpfs directories or empty bind mounts so data remains unavailable to Codex.
-- Network: isolated networking is used by default; `allow_host_network=true` opts into `--network host`. When `packet-capture` is enabled, sloptrap starts a separate capture helper container in the same Podman pod so the main Codex container does not receive `NET_RAW`.
-- Process context: standard runs drop capabilities, set `no-new-privileges`, use a read-only root filesystem, and keep scratch paths (`/tmp`, `/run`, `/run/lock`) on tmpfs. Capability-enabled runs may selectively add the runtime options required for the requested capability.
+- Network: isolated networking is used by default; `allow_host_network=true` opts into `--network host`.
+- Process context: standard runs drop capabilities, set `no-new-privileges`, use a read-only root filesystem, and keep scratch paths (`/tmp`, `/run`, `/run/lock`) on tmpfs.
 - Codex configuration: runtime flags are fixed to `--sandbox danger-full-access --ask-for-approval never`. Persistent Codex state is project-scoped under `${HOME}/.codex/sloptrap/state/`, while credentials are shared via `${HOME}/.codex/auth.json` and mounted read-only except during the `login` target.
 
 ## Threat Model and Limits
@@ -146,8 +136,8 @@ When the current manifest's capabilities are trusted and enabled, the container
 - **Outbound disclosure**: prompts and referenced data travel from the container to the configured LLM endpoint. Any file content within `/workspace` or environment data exposed to the process can appear in that traffic.
 - **Shared storage**: `/workspace`, project-scoped `/codex`, and `/codex/auth.json` are host mounts. Files written to these locations become visible on the host and to the LLM provider through prompts.
 - **Environment surface**: the container receives a minimal fixed environment (HOME/XDG paths, `CODEX_HOME`). The manifest no longer allows injecting additional environment variables.
-- **Process isolation**: standard runs keep a read-only root filesystem and no extra Linux capabilities. Capability-enabled runs deliberately relax specific runtime controls for the enabled feature, so they should be treated as a stronger trust decision than a default session. `packet-capture` now runs in a dedicated helper container so the main Codex container does not hold raw-socket capability.
-- **Networking stance**: traffic is unrestricted once it leaves the container. sloptrap does not enforce an allowlist or DNS policy. Host networking is opt-in per manifest; when it is combined with `packet-capture`, sloptrap warns and requires an explicit acknowledgement for each runtime launch because the capture helper will have raw packet access in the host namespace and may observe plaintext traffic or inject spoofed packets. If you require an offline or firewalled workflow, sloptrap is not an appropriate launcher.
+- **Process isolation**: standard runs keep a read-only root filesystem and no extra Linux capabilities.
+- **Networking stance**: traffic is unrestricted once it leaves the container. sloptrap does not enforce an allowlist or DNS policy. Host networking is opt-in per manifest. If you require an offline or firewalled workflow, sloptrap is not an appropriate launcher.
 - **Persistence**: Codex history and logs accumulate per project under `${HOME}/.codex/sloptrap/state/`. Sensitive prompts recorded on disk remain on the host after the session. Because `.git/` is ignored inside the container, any historical secrets in Git objects stay outside the LLM context unless explicitly surfaced in the working tree.
 - **Codex cache hygiene**: per-project state mounts remain writable by the container and hold prompts/history/state, while `${HOME}/.codex/auth.json` holds shared credentials. Rotate credentials regularly and protect both locations.
 - **Secret scanning**: sloptrap does not perform secret discovery or redaction; any credentials present in the project remain available to Codex and the upstream provider.