TT-7621 fix: act on a segment click instead of swallowing it

[nabalone]

Fix 2 of the PBT series. Into #527.

The fault

Clicking the segment immediately after the current one sometimes failed to fully change the selected segment, so a take recorded then went to the old segment.

After a segment finishes playing, handleRegionPlayEnd parks and arms pendingOvershootSwallowRef, because playback overshoot into the next region produces a spurious +1 segment change that would otherwise read as navigation (TT-7360). The swallow cannot tell that change apart from the user clicking the next segment, so it ate both.

The fix

The waveform now reports a click distinctly: useWavesurferRegions fires onRegionClicked from handleRegionClick, threaded up through useWaveSurfer → WSAudioPlayer → PassageDetailPlayer as onSegmentClick. A click is deliberate and therefore never overshoot, so the step disarms the swallow when one arrives. Playhead-driven selection still flows through onCurrentRegion unchanged — which is what the swallow exists for.

Additive throughout: every layer takes an optional callback, so other players are unaffected.

Result

Two reported behaviours fixed — the ignored first click, and the waveform selection disagreeing with the segment label (the same swallowed click from the other side). Both tests renamed to what they now assert.

• selection spec: 6 passing / 1 failing (the remaining failure is Record operable during playback, a separate fix)
• behaviour specs: 13 + 16 green
• jest WSAudioPlayer / MediaRecord / PassageDetailCarefulSpeech: 41 green

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR addresses a Phrase Back Translate (PBT) segment-selection defect where a user click on the next waveform segment could be swallowed by the “overshoot swallow” logic (intended to ignore playhead overshoot), causing the UI/recording target to remain on the previous segment.

Changes:

• Introduces a distinct “region clicked” callback from the wavesurfer region click handler and threads it up through useWaveSurfer → WSAudioPlayer → PassageDetailPlayer.
• Uses the new click signal in Guided Phrase Record to disarm pendingOvershootSwallowRef so deliberate clicks are not treated like overshoot.
• Updates Cypress CT selection specs to reflect the fixed behavior and strengthens assertions around correct take filing.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/renderer/src/crud/useWavesurferRegions.tsx	Emits a dedicated callback on waveform region click (distinct from playhead-driven selection).
src/renderer/src/crud/useWaveSurfer.tsx	Threads the new click callback into the regions hook API.
src/renderer/src/components/WSAudioPlayer.tsx	Adds an optional onSegmentClick prop and passes it through to the wavesurfer hook.
src/renderer/src/components/PassageDetail/PassageDetailPlayer.tsx	Plumbs onSegmentClick down into WSAudioPlayer.
src/renderer/src/components/PassageDetail/PassageDetailPhraseBackTranslate.selection.cy.tsx	Renames/updates selection specs to assert first-click behavior and correct take attribution.
src/renderer/src/components/PassageDetail/PassageDetailGuidedPhraseRecord.tsx	Disarms the overshoot swallow on deliberate waveform clicks.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[nabalone]

Addressed in new commit

[nabalone]

Note: de-flaking keeps Record off while a clicked segment plays

Pushed 2071f0b — this is a test change only, no product code touched.

That test (added by #527, unchanged by this PR) sampled the DOM every 25 ms for 6 s and failed if any single sample saw the reference audio playing and Record operable. The two flags are owned by different components on unrelated update chains — playing is WSAudioPlayer's own state, Record's operability is the step's allowRecord — so at the start of playback and at its end they flip on separate renders, and a sample can catch both live for a frame with nothing actually wrong. ~240 samples per run made hitting one of those windows a matter of scheduling luck, which is what the intermittent red here was.

It now waits for playback to start, settles 800 ms, and takes a single reading of both flags. Segment 3 runs 0:06–0:09, so that lands clear of both edges with ~2 s of margin even at half speed. Asserting playing in the same reading keeps it meaningful — if playback ended early the test fails there rather than passing on a Record button that is disabled for the wrong reason.

Trade-off: it no longer catches a Record button that is enabled only briefly mid-playback. That was never the reported defect, and a Record button that stays operable through the clicked segment still fails the test.

The tagged DEFECT: Record is operable while a newly clicked segment plays sibling still uses sampleDom and will inherit the same flakiness once its fix lands — worth giving it the same treatment then.