[7schmiede]

Closes #394.

• Cause: a slot directory removed without its purge (one without slot.json at the agent's start, or by an agent of an earlier release) left the lane's Compose projects and its groups' fixed-name networks running for good. On a node that shares its host, this used up Docker's address pools: 28 containers and 6 networks of two lanes ran for 10 days with no lease.
• Fix: sweep_orphan_projects runs every purge round (10 min). It removes the Compose projects of this agent's lanes whose slot has no lease, no directory and no purge under way.
  • They are found by name (<project>-<slot>, via slot_of_project, which also catches the <project>-search-<slot> kind) and by com.docker.compose.project.working_dir lying under this agent's slots. Another pool's agent on the same engine keeps its own (ADR-0034).
  • Their volumes stay (ADR-0038). The slot's devstack.lane=1 networks go after its projects. Right before each removal the slot is checked again, in case a lane of it starts right then.
• Clearer error: a lane whose own network cannot be created because the address pools are used up says the node's Docker has no network left and points to default-address-pools.
• Docs: docs/pool.md (Run a node) covers default-address-pools and what the agent cleans up. Changelog updated.

No review card: a bug fix within ADR-0038's rules (a stopped lane's data is kept, its containers are not).

Tests

• a_gone_lanes_projects_are_found_by_slot_and_place checks four cases: a gone slot's two projects are found once each; a held slot's project is kept; a project under another root is kept; a project that is not a lane's is kept.
• cargo test -p devstack-node --lib: 105 passed. cargo clippy -p devstack-node --all-targets -D warnings and cargo fmt are clean.
• Not tested end-to-end on a node: the two leaked lanes were already removed by hand.

🤖 Generated with Claude Code