[fortmarek]

Summary

Two targets that declare the same cacheable action could both run it. This is what made spec/apple_explicit_modules_spec.sh:75 fail intermittently on shellspec (macos-latest) (for example once run 42596832361 on main), where Left and Right compile the same Clang modules and the spec expects one of them to reuse the other's result.

The race:

1. Target B probes the cache and misses, because target A is still running the action.
2. B waits for an execution slot, which A holds.
3. A stores its result, then releases the slot and the action lock together.
4. B takes the lock without contention. The re-probe only ran on contention, so B ran the action again.

The fix always re-probes after taking the lock and drops the now-unused contention flag from with_action_lock_and_permit. The cost is one extra cache lookup per action that actually executes; with a remote cache, a true miss asks the remote twice.

Verification

• Reproduced on macOS 27 under load (6 parallel loops of the spec's steps with --cpu-limit 3): 18 of 36 runs failed, all at the shared .pcm check, with both targets recording miss for the same NativeValue.pcm, SwiftShims.pcm, and _SwiftConcurrencyShims.pcm digests. With the fix, 36 of 36 passed.
• shellspec spec/apple_explicit_modules_spec.sh: 3 examples, 0 failures.
• New regression test an_action_queued_behind_its_own_run_reuses_that_result runs two builds of one action on a single slot. It fails on the old code (the action runs twice) and passes with the fix.
• cargo test -p once-cli --bin once commands::graph::analysis, cargo fmt --check, and cargo clippy -p once-cli --all-targets -D warnings pass.