Fix data races in doppler run --watch and --mount

[watsonian]

Running doppler run --watch with a race-instrumented build reports data races. All of them exist on master, and none are in the new signal handling code. The watch stream handles each event in its own goroutine, and the connection retry loop runs alongside them. Four variables were shared between those goroutines without synchronization. lastUpdateEvent was written by each update event before it took watchMutex. watchedValuesMayBeStale was set by the retry loop and read by the connected event outside any lock. watchRetrySleep was reset by event handlers while the retry loop doubled it. lastSecretsFetch was already protected by watchMutex, but it now shares the new lock so that one rule covers all four. That lock, stateMutex, is held only briefly for reads and writes and never while taking another lock.

Two related accesses are tightened as well. terminatedByWatch is now an atomic flag, because its write to true was never covered by the mutex that a comment said protected it. The goroutine that waits for the child now receives the child and its cleanup as arguments, instead of reading variables that the next restart reassigns. The race detector doesn't flag either of these on master, probably because os/exec synchronizes internally around Wait. These two changes stop relying on that implicit ordering rather than fixing a reproducible race.

--mount had one more race of its own. cleanupFIFO sets a flag that the goroutine writing to the pipe reads when its next open fails, and the flag was a plain bool. It's now atomic.

The new tests fail on every run without the fix and pass with it. TestWatchConcurrentEventsHaveNoDataRaces sends updates while a restart is in progress, and TestWatchReconnectHasNoDataRaces makes the mock API drop the watch stream so doppler reconnects. Both run a race-instrumented doppler built on first use (or one supplied through DOPPLER_TEST_RACE_BINARY), and fail if it reports a race. The --mount race depends on goroutine scheduling, and a doppler run-level test caught it only about 75% of the time. TestMountSecretsCleanupWhileWriterIsActive instead calls MountSecrets directly and forces the order that triggers it. CI doesn't run tests with -race, so TestMountSecretsCleanupHasNoDataRaces runs that test under the race detector in a subprocess. It skips itself when the suite already has the race detector on, or under -short.

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}