isolation: agent containers, networks and the squid proxy are never swept, only HOME volumes

[naashw]

Intent

Container-runtime resources created for a task are released on the graceful path only. teardownEgressProxy (task-isolation.ts:1018) removes the squid container and both networks, and its single caller is the drain handler in workspace.ts:370, reached from SIGINT/SIGTERM.

The boot sweep does not compensate. sweepOrphanedHomeVolumes (task-isolation.ts:1480) covers HOME volumes and nothing else; workspace.ts:617 calls taskManager.sweepOrphanedVolumes() and there is no equivalent for containers or networks.

So an ungraceful death of the CLI (SIGKILL, OOM killer, host crash, and per #71 SIGHUP on terminal close) leaves behind:

• the squid container codesema-proxy-<id>, started with -d --rm (:970-985) — --rm only fires when the container itself exits, and squid does not exit
• both networks codesema-net-<id> and codesema-egress-<id> (:951-965)
• the agent container, which keeps running its turn with full Bash inside the worktree while the host-side watchdog that was supposed to bound it is gone

The last point is the one that matters: --rm will eventually clean the agent container up, but only after an unsupervised turn has finished writing to the worktree. The kill path is by container name (:2037-2038) and it dies with the process that knew the name.

Related but distinct: #71 covers orphaned agent processes and the missing SIGHUP handler; #72 covers boot reconciliation inferring orphanhood without a liveness signal. This issue is about the runtime resources nothing reclaims, which remain even once those two are fixed.

Scope

In scope:

• Squid containers, the two per-workspace networks, and agent containers left by an ungraceful exit.
• The boot sweep, which today reclaims only HOME volumes.

Out of scope:

• Orphaned agent processes and signal handling (shutdown: out-of-turn agents survive Ctrl-C and terminal close #71).
• Task status reconciliation (tasks: boot reconciliation assumes a dead server left no live agent #72).
• The generated squid.conf in tmp, already documented as harmless if it outlives the process (:1041-1043).

Approach

Extend the labelling already used for HOME volumes (HOME_VOLUME_OWNER_LABEL, :331) to every container and network the workspace creates, then widen the boot sweep to reclaim any labelled resource whose owning workspace is no longer alive. The owner check must stay uid-scoped, for the same reason spelled out at :333-336.

ADDED Requirements

Requirement: Runtime resources MUST be reclaimable after an ungraceful exit

The system SHALL reclaim the containers and networks it created once the workspace that created them is no longer running, without requiring that workspace to have exited gracefully.

Scenario: the CLI is killed outright

• GIVEN a workspace running a caged turn, with a squid container and its two networks up
• WHEN the CLI process is terminated with SIGKILL
• AND a new workspace starts later on the same machine
• THEN the boot sweep removes the orphaned squid container and both networks
• AND it does not touch resources owned by another live workspace or another OS user

Scenario: an agent container outlives its supervisor

• GIVEN a caged turn in flight
• WHEN the CLI dies without running its kill path
• THEN the orphaned agent container is reported at next boot
• AND it is removed rather than left to finish its turn unsupervised

Tasks

1. Label what is created

• 1.1 Stamp the workspace owner label on the agent container, the squid container and both networks at creation
• 1.2 Keep the uid scoping used by the HOME volume label

2. Widen the sweep

• 2.1 Generalise sweepOrphanedHomeVolumes to containers and networks, keeping the "never touch a live workspace" guard
• 2.2 Report reclaimed resources through the same notice channel as the volume sweep

3. Prove it

• 3.1 Test: labelled resources of a dead workspace are reclaimed at boot
• 3.2 Test: resources of a live workspace, and of another uid, are left alone