[danshapiro]

Fixes four freshell-supervisor tests that failed now and then in pre-push hooks and CI, mostly when the machine was heavily loaded. No test was skipped and no assertion was loosened.

The tests, their causes, and the fixes

1. provider_accepted_completion_retries_after_registry_success_on_fresh_healthy_startup

Failed with Registry::open ... Busy when the test reopened the registry. This test had two separate causes:

• A child process kept the registry lock alive (product bug). The registry lock is an flock. When another thread starts a child process, the child holds a copy of every open file until it runs exec. That copy kept the lock held after the registry was dropped, so a reopen right afterwards got Busy. In a scratch test with 4 threads starting /bin/true while the registry was opened and dropped in a loop, 1,814 of 3,000 reopens returned Busy before the fix and 0 of 3,000 after. Fix: the registry's lock now unlocks explicitly when it is dropped, which releases it for every copy at once (OwnerLock in registry.rs, using std's File::try_lock/unlock, with a warning log if the release fails). New regression test: dropped_registry_releases_ownership_while_a_spawning_child_shares_its_lock.
• A control connection kept the supervisor until after it had replied (product bug). serve_control answered each connection in a separate task that held its own copy of the supervisor, and so of the registry, until after it wrote the reply. The test reads the reply, drops its handles and reopens the registry. If that task's thread was paused for 10–20 ms between writing the reply and finishing, the reopen got Busy. With a 100 ms pause injected at that point, the test failed 3 out of 3 times; with the fix and the same pause it passed 6 out of 6. Fix: the connection now lets go of the supervisor before it writes the reply (serve_control_connection in service.rs). New regression test: control_connection_releases_supervisor_before_it_replies reopens the registry at the moment the reply is written. It got Busy before the fix and passes after it, for both a valid and a malformed request.

2. recovery_five_natural_successes_exhaust_durable_budget_until_manual_retry

Did not fail in about 1,100 runs. It uses only the registry, so the only way it can get Busy is the child-process lock copy described above. The same registry fix covers it.

3. retained_output_owned_preparing_replacement_keeps_committed_prior

Got Busy 4 times in 96 whole-suite runs, from the same child-process lock copy. The same registry fix covers it.

4. provider_mountpoint_candidate_target_joins_owned_preparation_and_cleanup

Failed in 52 of 64 whole-suite runs under load ("early eof", UnexpectedEof, "image lookup timed out", or losing track of its helper). Cause (test bug): the test used real 250 ms time limits and a 50 ms cancellation, so under load the limits ran out at random points instead of at the stall each case is meant to test. Fix: the test now runs on tokio's paused clock. The fake helper reports when it is holding back the exchange being tested, and only then does the test move the clock past the limit. If the code under test hangs, the test fails after 60 real seconds instead of hanging forever. Removing either of the product's time limits makes it fail that way, as it should. Adds tokio test-util as a dev-dependency.

Stress results after the fixes

• 48 whole-suite runs, 16 at a time, at machine load 260–547 on 96 cores: none of the tests above failed.
• 80 runs of just these tests (plus the new regression test), 8 at a time alongside those suite runs: 80 of 80 passed.
• Earlier runs on this branch: 0 Busy failures in 128 whole-suite runs and in 320 runs alongside process-starting tests; test 4 passed 640/640 and 960/960 on its own under load.
• cargo fmt --check and clippy -D warnings are clean, and the pre-push hook passed.

Not fixed here

These tests still fail sometimes under heavy load. They fail the same way on main and are outside this change:

• provider_claude_nested_source_reply_requires_live_scope_after_private_ipc ("must not reacquire the held soul lifecycle lock: Elapsed")
• provider_claude_source_helper_uses_private_bound_ipc_without_creating_stable_home
• native_auth_uses_private_ipc_and_cleans_only_verified_owned_helper ("helper must actually run")

🤖 Generated with Claude Code