fix(tmux): synchronize controlModeDone reads to fix data race

[tstapler]

Summary

Fixes a genuine Go data race in session/tmux/control_mode.go, confirmed via go test -race and currently failing the Test CI job on every PR (pre-existing on main, newly surfaced now that CI can get past the LFS quota blocker far enough to run -race tests).

Root cause

StopControlMode writes t.controlModeDone = nil (and closes it) while holding t.controlModeSubMu.Lock(). Two reader goroutines — readControlModeOutput and monitorControlModeErrors — each captured t.controlModeDone at their first line with a comment acknowledging the hazard ("capture before StopControlMode can nil it"), but neither actually took the lock. The race detector caught the monitorControlModeErrors instance:

Write at 0x00c00011a828 by goroutine 254:
  (*TmuxSession).StopControlMode()  control_mode.go:167
Previous read at 0x00c00011a828 by goroutine 282:
  (*TmuxSession).monitorControlModeErrors()  control_mode.go:322

readControlModeOutput has the identical unsynchronized-read pattern one function up, so it's fixed too for consistency — the race detector just hadn't happened to schedule that interleaving in this run.

Fix

Wrap each capture in controlModeSubMu.RLock()/RUnlock(), matching the existing RLock-for-reads convention already used elsewhere in this file (sendCMCommand, SendInputViaControlMode). The snapshotted channel value remains safe to select on after unlock — only the read of the shared struct field itself needed synchronization.

Testing

• go test -race ./session/tmux/... -run TestControlModeSurvivesRestart -count=5 — clean, 5/5, no race warnings (this is the regression test from BUG-042, commit b6e76be7d, that was correctly exposing this pre-existing race)
• go test -race ./session/tmux/... — full package suite, clean
• go test ./session/tmux/... (no -race) — clean; one test (TestEnsureServerRunning_NoOp) flaked once under full-suite tmux-server contention but passed 3/3 in isolation and on a full-suite re-run, unrelated to this change
• make build, make lint — clean

Impact

• Scope: session/tmux/control_mode.go only, two reader goroutines
• Breaking changes: none
• Performance: negligible — RLock is only taken once per goroutine at startup to snapshot a channel pointer, not in any hot path
• Dependencies: none

Reviewer notes

• Focus areas: confirm the RLock choice is correct (read-only access to controlModeDone, consistent with other RLock reads in this file) rather than a full Lock()
• Known limitations: none
• Follow-up tasks: none identified

🤖 Generated with Claude Code

[github-actions]

✅ Registry Validation

Registry Validation
===================

Building backend scanner...
Scanning backend features...
Wrote 117 feature files to /tmp/tmp.jkwBA8pTzj/backend
Wrote 15 feature files to /tmp/tmp.jkwBA8pTzj/backend
Wrote 45 feature files to /tmp/tmp.jkwBA8pTzj/backend
Wrote 7 feature files to /tmp/tmp.jkwBA8pTzj/backend
Wrote 11 feature files to /tmp/tmp.jkwBA8pTzj/backend

=== Backend Registry Diff ===
Committed: 179  Generated: 179  Divergence: 0.0%
⚠️  110 feature(s) missing // +api: marker (markerFound: false)

✅ Registry validation passed. Divergence: 0.0%

Test Coverage: 19/179 features have testIds (10.6%)

Divergence > 2% blocks merges. Coverage reporting is advisory only.

[tstapler]

Closing — this was accidentally opened against the work repo instead of the personal fork (tstapler/stapler-squad), where the equivalent fix was merged as part of smtg-ai#276.