fix(daemon): clean up Kubernetes runtime plane hygiene

[spacedragon]

Part of #955.

What changed

• remove the orphaned Sandbox drain-annotation watch and its stale launch outcome/tests
• scope runtime-probe claim names to a daemon member using a hash of AC_K8S_MEMBER_ID
• label probe claims with a 15-minute expiry and periodically reap abandoned claims using UID/resourceVersion-fenced deletes
• require AC_K8S_SANDBOX_NAMESPACE and use it instead of the daemon Pod namespace
• update the cluster design docs for the two-namespace pool layout and probe lifecycle

Why

The deleted per-org operator was the only producer of agentconnect.md/drain-requested, so the daemon watch had become dead machinery. A fixed probe claim made simultaneous pool members race on one SandboxClaim, while member-scoped claims needed restart-safe garbage collection. Deriving the resource namespace from in-cluster config also targeted the daemon namespace rather than the shared sandbox namespace.

Impact

--k8s now fails fast unless deployments provide AC_K8S_SANDBOX_NAMESPACE and a member-unique AC_K8S_MEMBER_ID (normally the Pod UID via the Downward API). Abandoned probe claims are bounded without touching ordinary agent claims, and stale sweeps cannot delete a same-name replacement.

Validation

• 83 related daemon tests passed across the K8s runtime plane, client, driver, metrics, ACP E2E, credentials, and tunnel suites
• pnpm --filter @agentconnect.md/daemon typecheck
• targeted ESLint and Prettier checks
• repository pre-push eslint .
• full daemon suite on the initial revision: 3510 passed; 3 unrelated environment/live-runtime failures (provider quota/model behavior and host GIT_ASKPASS contamination)

[agentconnect-md-test]

Found one blocking Kubernetes lifecycle regression. Scoping the runtime-probe claim per active daemon member fixes the simultaneous-start collision, and the explicit sandbox namespace change is internally consistent. However, the documented member identity is the Pod UID, which changes on every Pod replacement, while probe claims have no owner or stale-member cleanup path. If a daemon exits after creating the probe claim but before its finally deletion completes—or if that deletion fails—the replacement hashes a different UID and can never reuse or remove the old claim. Because the claim retains its Sandbox and workspace volume, interrupted probes and rollouts can accumulate permanent resources; the previous fixed name at least let a later process converge on and delete the same claim. Please retain member isolation while adding restart-safe ownership or garbage collection for abandoned probe claims.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}

[agentconnect-md-test]

The new label-and-expiry sweep bounds abandoned probe resources and addresses the previous permanent-orphan finding, but one blocking stale-delete race remains. The sweeper decides expiry from a LIST snapshot and then deletes only by claim name. A container restart within the same Pod keeps the same member ID, so probeRuntimes() can delete and recreate that deterministic claim name with a fresh expiry while another member is processing an older snapshot. The delayed GC delete then removes the fresh live claim, tearing down the Sandbox during the daemon’s startup runtime probe; that probe is not retried, so the member can remain advertising no runtimes. Please fence GC deletion to the listed object incarnation, for example with a Kubernetes UID/resourceVersion delete precondition.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}

[agentconnect-md-test]

Approved. The explicit sandbox namespace and member-scoped probe identity are applied consistently, the orphaned drain-watch machinery is removed cleanly, and probe cleanup now has a bounded recovery path. The follow-up correctly fences each expired-claim delete with the UID/resourceVersion from the LIST snapshot and treats a precondition conflict as a superseded object, so a stale sweep cannot delete a freshly recreated live probe claim. I found no remaining blocking issues in the complete patch.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}