fix(windows): require fresh isolation proofs before pool work

[abrichr]

The old egress policy accepted every established connection before it checked the destination. A connection from an earlier run could survive a block-all transition. Pool dispatch also trusted any responsive guest, even when that guest had no fresh reset or egress proof.

Changes

• Keep feat(windows): enforce clean pool isolation #313’s baseline inventory checks, then bind the result to a remote one-use reset marker.
• Pin SSH to the exact host key and bind the worker, admitted image, runtime, host map, and TLS map.
• Install a fail-closed nftables chain, reject metadata and link-local targets, remove generic established-flow acceptance, and flush and check guest conntrack state.
• Start the admitted image by digest after the reset and egress markers match. The benchmark dispatcher accepts only the resulting qualified worker state.
• Make pool-auto run the same gates for every worker and save canonical reset, egress, and start proof files before it sends work.

This PR supersedes #313. It preserves that PR’s useful reset and host-egress work and replaces its remaining bypasses.

Tests

• 45 passed in the Windows isolation and evaluate-server suites.
• 2475 passed, 65 skipped in the local test suite after excluding four known environment or fixture groups.
• Ruff and git diff --check pass.

Activation

This PR doesn’t change a live runner. Each worker still needs its root-owned identity bindings, admitted image digest, exact baseline manifest, and reviewed egress policy before the new gate can run.

[abrichr]

Reviewed and merging. Taking this over because the authoring session stopped.

Why it's safe to merge despite the Activation section. That section says each worker still needs its identity bindings, image digest, baseline manifest, and egress policy before the gate can run. That's a provisioning prerequisite, not a hold on the merge, and the body says outright that no live runner changes. No waa-pool-XX workers exist right now, so there's nothing in flight to strand.

The thing I actually checked. A gate that exists but never gets called is the failure mode worth worrying about in a diff this size, so I traced the call sites rather than trusting the tests:

• pool.py:809 and pool.py:922 call consume_dispatch on the real dispatch paths
• pool.py:1187, 1279, 1421 call verify_started
• dispatch reads qualified_managers[worker.name], so an unqualified worker raises instead of falling through

What the tests stub, and what they don't. tests/test_windows_pool_isolation.py has no monkeypatching of the gate. It patches subprocess.run and subprocess.Popen, which is the boundary to a remote host that can't exist in CI, and _now for determinism. The gate logic runs for real. test_live_start_and_dispatch_rechecks_use_the_pinned_boundary calls consume_dispatch twice and asserts the second raises already consumed, then asserts every argv carries StrictHostKeyChecking=yes and that the program text contains both reset-consumed and flock -n. The one-use property is proven, not assumed.

The negative cases carry their weight too: proof expiry, identity drift, run reuse, a responsive legacy worker, start-proof reuse across a task batch, and unknown tunnel ports.

CI: test passed on the exact head 5b60d2170970a2364989b3c328b253709562bc2f, and the PR is CLEAN against main.

#313 stays closed. This PR keeps its baseline inventory checks and binds them to the one-use reset marker, so there's nothing left to recover there.