TT-7621 fix: follow real segment changes, ignore spurious ones

[nabalone]

Split out of #527 so that PR could merge as tests-only. #527 has since merged, so
this now targets develop directly and carries the one behaviour fix plus the
write-up that goes with it.

The bug

Reported from hand testing:

I record the first segment, then the third, and then try to go back and record
the second — it records into and replaces the third.

Clicking segment 2 moves the waveform selection and the playhead there, but the
guided-record step stays on segment 3. The next take is uploaded with segment 3's
source-segments, so it lands on top of the take already there. Nothing warns the
user; the label still reads the old segment, and the audio they just recorded for
segment 2 has silently overwritten segment 3's.

Two other reports turn out to be the same fault seen from different angles:

• "the yellow highlighting briefly jumps to the next segment" — the waveform paints
  from the engine's index while the label comes from the step's own index, so when
  a click reaches only the engine the two disagree (briefly in the recoverable
  case, indefinitely in the one above);
• Record being live for the segment the user thought they had just left.

Root cause

PassageDetailContext.currentSegmentIndex is written by three places using two
different numberings, and nothing forces agreement — the setter takes a bare
index: number:

	Convention	Where
Writes	1-based (sortedIndex + 1, 0 = whole)	business/player/usePlayerLogic.ts:113 — the waveform
Writes	1-based by accident (table row)	PassageDetailMarkVerses.tsx (925, 934, 1079, 1389, 1477)
Writes	0-based clause index	PassageDetailGuidedPhraseRecord.tsx — 17 call sites
Reads	1-based	PassageDetailItem.tsx:246, DiscussionList.tsx:107
Reads	0-based	crud/useWavesurferRegions.tsx:955

The step learns the selection moved by watching currentSegmentIndex change. It
never uses the number — it derives its own index from the region via
findClauseIndex — so the field is purely a change signal to it. That is exactly
why the collision went unnoticed: clicking segment 2 makes the waveform write
1 + 1 = 2, and the step had itself just written 2 for segment 3. Same value,
so the dependency never changed, the navigation effect never re-ran, and the step
stayed put while everything visible moved.

The fix

currentSegmentSeq — a token in PassageDetailContext incremented whenever the
current segment actually changes. The step's two navigation effects watch it
instead of inferring a change from the index. currentSegmentIndex stays in the
dependency lists because the value is still read there.

This is deliberately the small fix. Unifying the numbering is the right repair but
touches every caller across Mark Verses, the players and the guided-record step,
and Noel's call is to do it after the next release.

Second fix: an overshoot onto a recorded clause steals the selection

The same navigation effect, the other direction. Reported from hand testing of
this branch:

I record the first segment, right-arrow twice to the third, record it, then
left-arrow to the second. It auto-plays the second segment as expected, but
afterwards the third segment is highlighted, when the second should still be
highlighted for me to record.

Parking after an auto-play arms pendingOvershootSwallowRef, because one spurious
region-in on the next clause follows it — playback overshooting the clause
end, or the recorder mounting once Record is allowed. The effect only consulted
that swallow after its completed-clause branch, so when the clause the
overshoot landed on already had a take (segment 3 here) that branch took the
overshoot for a real move: the label, the yellow selection and the phase all
followed it, and segment 2 went back to pending under a user who was waiting to
record it. Pressing Record then filed the take on segment 3, over the take
already there.

The swallow is now decided before the completed-clause branch, and stops playback
itself, since it no longer inherits the stop from the code below it.

Test

PassageDetailPhraseBackTranslate.selection.cy.tsx —
"follows a click back to an earlier segment and files the take there" loses its
DEFECT:/@known-defect marking and now asserts the real consequence, not just
the label: the third take's uploaded source-segments is segment 2's span
(3–6s), and segment 3 still holds exactly one take.

"keeps the parked segment when playback overshoots onto a recorded one", in the
same spec, covers the second fix. It drives the reported arrow sequence, then
uses the harness's tapSegment — an engine segment change with no click behind
it, which is what that spurious region-in looks like to the step — and asserts
that the label and the painted selection both stay on segment 2, that Record stays
armed, and that the next take files at 3–6s with segment 3 still holding exactly
one take.

All four PBT specs on this branch, with develop merged in: 35 passing, 7
pending (@known-defect), 0 failing. npm test matches develop exactly - the
same two suites fail there (MetadataView, on the pre-existing
React.SubmitEvent type error, and a VertListDnd snapshot).

ADR 0010

docs/adr/0010-current-segment-index-numbering.md records the whole situation so
the deferred work is actionable: who writes and reads which convention, what it
broke here, the recommended unification (pick 1-based; make the convention
unmissable rather than conventional), and what becomes removable when it happens —
currentSegmentSeq, its ref, and the two dependency-list entries. The other
TT-7621 fixes (#528, #529, #530, #532) are unrelated to the numbering and stay.

It also documents a separate latent off-by-one the same split causes, at
crud/useWavesurferRegions.tsx:955:

onRegionGoTo(regarray[defaultRegionIndex]?.start ?? 0);

defaultRegionIndex is the context's currentSegmentIndex, so a region load that
reads a 1-based value selects the segment after the current one. Every region
load is affected — WSAudioPlayer 889, 1042, 1370, 1517 (loadRegionsJson, which
Split, Combine, segment undo and Reset all call). It is not reproducible from PBT
(an effect there continuously re-asserts a 0-based index, so a load usually reads
the right convention by accident); Mark Verses and the generic segment player are
where to look. No fix attempted here.

Review note on the numbering

Every currentSegmentSeq touchpoint in this diff is scaffolding around the
numbering split, not something we want permanently. Reviewers: read it as "this
exists because the index cannot be trusted as a change signal", and expect it to
come out with ADR 0010's unification after the next release.