Flaky test: runtime_chat_relay failed_state_writes…exact_retry_reopens fails under CI parallel load (owner-lock conflict)

[Hmbown]

Sibling to #5605 (same class: full-suite/parallel-load flake).

Observed: Safety gate on PRs #5730 and #5734 (2026-08-30, within minutes of each other, same code shape as main) failed on runtime_chat_relay::tests::failed_state_writes_never_become_in_memory_authority_and_exact_retry_reopens:

panicked at crates/tui/src/runtime_chat_relay.rs:1710:10:
open Runtime Chat host: "Another Codewhale process already owns this Runtime Chat account session."

PRs #5732/#5733 on the same base passed it. Nothing in either failing PR touches runtime_chat_relay.rs — pre-existing main code, schedule-dependent.

Mechanism notes for whoever picks it up: the scope lock is flock(LOCK_EX|LOCK_NB) on scope-<sha>/ under a per-test tempdir (RelayScopeLock::acquire, runtime_chat_relay.rs:1520+). flock conflicts are per open-file-description, so a second open of the same path in the same process conflicts even single-process. The test drops the host then reopens the same root (drop(host); open_host(root) at ~:2216). If any host internals (RuntimeThreadManager background tasks) defer the fd close past drop(host), the reopen loses the race — which would explain scheduling-dependent flakiness. The map_err at open (:260) discards the underlying io error, which hides the real errno — keep the source error in the message when fixing.

Acceptance: the test (and its siblings using open_host) passes under repeated full-suite parallel load (e.g. 20 consecutive Safety-gate runs or a stress loop with --test-threads maxed), with the underlying io error preserved in the failure message.

[Hmbown]

Evidence check on #5736 (merged today as eadefad, on origin/main):

• It touches exactly one file, crates/tui/src/runtime_chat_relay.rs (+13 / -3), and only the map_err in RuntimeChatRelayHost::open: a WouldBlock from RelayScopeLock::acquire still reads "Another Codewhale process already owns this Runtime Chat account session."; every other failure now reports Runtime Chat could not take its owner lock: {error:#} with the source chain.
• It is therefore the diagnosis half only, as the PR body says. It does not change the lock, the drop(host); open_host(root) sequence, or test scheduling. This issue stays open.

What the source says about the mechanism (read on origin/main, not reproduced):

• RuntimeChatRelayHost derives Clone and holds _scope_lock: Arc<RelayScopeLock>, but nothing in the file clones the host or the lock into a thread, and the failing test is a plain #[test] with no runtime, so a deferred fd close past drop(host) needs a holder I could not find. The per-open-file-description flock explanation is possible but not yet evidenced.
• Before fix(tui): report Runtime Chat owner-lock IO faults truthfully #5736, any error inside RelayScopeLock::acquire (the open, the metadata check, set_permissions, or the flock itself) was reported as ownership. Under full-suite parallel load something like EMFILE (too many open files) on the reopen would have produced exactly the message we saw. The new message settles this either way on the next occurrence.
• The Safety gate runs cargo test -p codewhale-tui --lib --locked -- command_safety auto_review authority sandbox (ci.yml:285); this test is selected by the authority substring, so it runs in parallel with every sandbox/authority test in that job, which is where the load comes from.

Next step is unchanged from the acceptance criterion: the next Safety-gate failure on this test will carry the real errno; whoever picks it up, please paste it here.

Sibling #5605 is not covered by #5736 either: remote_control.rs was last touched 2026-08-24 (7b66566) and #5736 does not touch it or runtime_threads.rs.

[Hmbown]

Fix landed: #5736 (eadefad, 2026-08-30) addressed the owner-lock conflict; the relay test has not appeared in the flake table since (the known-flakes ledger from 2026-08-31 lists exec_persistent_service, runtime_threads and heartbeat, not this one). Reopen with a fresh failing run if it recurs.