main is red on check-aarch64-darwin: compile_invalid_seat_does_not_block_existing_live_resync_watch times out waiting for the resync event

[schickling-assistant]

Summary

main is red on check-aarch64-darwin. Every PR branched off it inherits the failure, so a red
darwin job currently says nothing about the PR that carries it.

test run::tests::compile_invalid_seat_does_not_block_existing_live_resync_watch ... FAILED
thread '…' panicked at src/run.rs:4100:14:
correcting another declaration must not reseed and hide the live transition
test result: FAILED. 515 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 11.33s

check-x86_64-linux is green on the same commit.

Where it fails

src/run.rs:4099-4100 — the last step of the test, after the corrected seat is confirmed adopted:

let corrected_event = wait_for_resync_event_change(&live_dir, &first_event)
    .expect("correcting another declaration must not reseed and hide the live transition");

wait_for_resync_event_change returned None, i.e. no changed resync event appeared within its
wait window. The assertions before it all pass, so the reconcile half of the test is fine; what does
not arrive in time is the watcher-driven event.

Evidence that this is timing, not a code regression

• Green at 969c33d (fix: preserve resync absence and profile admission safety #364), red at 4c0c760 (fix(agent-publish): accept the in-place agent.kdl.candidate spec source #354) — the very next commit.
• git diff 969c33d 4c0c760 touches only src/agent_publish.rs and tests/agent_publish.rs.
  Neither the test nor anything it exercises in src/run.rs or the resync watcher changed between
  the green and red runs.
• Linux passes both.

So the most likely reading is a darwin-specific latency sensitivity in the wait — plausibly the
FSEvents-backed notify path being slower to deliver than inotify, especially under a loaded
runner — rather than a behavioural regression. I have not reproduced it (no darwin host here), so
that is a hypothesis from the diff and the platform split, not a diagnosis.

Runs

• main @ 4c0c760: run 33159684036, job 98810849678 (failure)
• main @ 969c33d: passing
• Also reproduces on an unrelated PR branched from 4c0c760: run 33183584985, job 98890717227,
  identical test, identical line, identical 515/1 split.

Why file rather than fix

A red base makes every downstream darwin signal uninterpretable, which is the part worth recording
even if the fix is one deadline constant. I have not touched it — the wait budget is a real design
choice about how long the watcher is allowed to take, and picking a number without a darwin host to
measure on would be a guess.

Possibly related: #315 (codex_app_server lib tests load-flaky on macOS, pass isolated) and #356
(darwin lifecycle tests consuming behavior deadlines during fixture scheduling) — both are the same
shape of "darwin timing eats a deadline", and #356's fix may simply not cover this call site.

Posted on behalf of @schickling

field	value
agent_identity	dev3.direct.claude.gvacdkt7
session	dev3.gvacdkt7
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	Claude Code
agent_tool_version	2.1.237
agent_runtime	Claude Code 2.1.237
tooling_profile	dotfiles@cab57ad