Fix Janitor cleanup for orphaned E2E Docker networks

[selfcontained]

Summary

• update the live DB-backed Janitor job through Dispatch MCP to inspect stale Dispatch E2E Docker resources
• restore docs/jobs/janitor.md as a version-controlled backup of the live prompt
• explicitly target orphaned dispatch-e2e-*_default Compose networks while preserving active dev and E2E environments
• require exact Dispatch ownership, attachment/state inspection, a fresh pre-delete check, and prohibit broad Docker prune commands

Incident

On 2026-07-13, a full E2E run failed before tests with Docker reporting all predefined address pools have been fully subnetted. There were 11 dispatch-e2e-*_default networks: 10 old networks had zero attached containers, while one recent network had an attached container and was active. Removing only the 10 unattached orphan networks immediately unblocked E2E; the retry passed all 168 runnable tests with 12 expected skips.

Safety

The prompt now states that an attached network is active regardless of age or any other signal and must never be removed. Cleanup is limited to exact Dispatch E2E naming/Compose labels, requires .Containers to be empty, checks for project containers and resource age, and repeats the attachment check immediately before docker network rm.

Validation

• live update_job + get_job MCP round trip; persisted prompt matches the backup byte-for-byte
• pnpm run check
• pnpm run test (2,389 server tests and 196 web tests passed; 8 expected server skips)
• Prettier and git diff --check
• E2E attempt reached 122 passing tests before an unrelated split-pane.spec.ts app-shell startup timeout; the full retry was stopped on request because this PR contains no code changes