agent_harness_e2e stacks share a process-global tool registry, so outcomes can depend on test order

What happens

Tests in tests/agent_harness_e2e.rs boot agent stacks that register tools into a process-global tool registry. env_lock() serialises them so two stacks are never live at once, but it does not restore registrations when a test finishes. Each stack leaves its registrations behind for whatever runs next.

The consequence is order dependence: a test's outcome can differ depending on which stacks ran before it in the same process. That is invisible while the suite happens to run in a stable order, and it surfaces as an unreproducible failure when the order changes — a new test, a filter, a different --test-threads.

Why it matters more than usual here

This harness is the main defence for agent routing, and routing behaviour is defined by which tools are registered and visible. A leaked registration from a previous stack is not noise in this suite; it is the input under test. #6302 already showed how a test whose inputs are shaped differently from production can pass while production is broken.

Scope

Not specific to the #6302/#6304 tests — it applies to every test in the file that boots a stack. Filed separately from the test-hardening issue for that reason.

Ask

Restore the registry around each stack (snapshot/restore, or a scoped registration handle whose Drop unregisters), so a test's registrations cannot outlive it. Then a deliberate order change should not alter any outcome, which is the check worth having.

Provenance

Raised by the tinysweeper/security lane on ddeb0d65c (#6304), reported after the PR had already merged. That lane ran degraded — code retrieval unavailable (openrouter embeddings 403, daily budget exceeded) and 3 memory calls failing (cortex 502) — so it reviewed the diff alone; this finding is independent of that limitation and holds on its own.