Stop during a Drive join can add the joining Copy back to capturing after Stop #957

Summary

If Stop lands while the audio thread is running a join block, the Copies that block claimed are added back to capturing after Stop, so a stopped Take can keep feeding a Copy.

Why it matters

Stop should end capture for every Copy. A Copy re-added after Stop can write past the Take's end or leave its writer waiting, and it sits on the real-time path, where a race like this is hard to see in a device Take.

Done when

• A test shows stopCapturing during a join block leaves no Copy capturing afterward (red first).
• The fix PR is merged, using atomics only (ADR 0002).
• Eric's device Take from the next [internal] tag: Stop during a Drive join mid-Take ends cleanly, with no Stems written past Stop.

Details

Found by agent3 while fixing #945 (PR #956); it is older than that change. In Capture.receive, the join block claims pending requests and then marks those Copies as capturing. If stopCapturing runs between the claim and that step, the claimed Copies are added back after Stop. agent3's suggested fix is one line: stopCapturing sets every stoppedFeeds bit (from #544), so the join block drops them.

A second, smaller race from the same review (partial overlaps leaving a Copy one block out of line) was left unfiled by Eric's choice; it is described in PR #956.

Verified on main 2026-10-24 at 61d09fe