fix(app): make the turn navigator thin, instant and obvious - #57672

Kit tried the merged turn navigator (#57572) in OpenCode Beta and found it confusing. The ticks read as a thick grey bar, hovering made a bulge, the preview came late, and nothing explained what the rail does. #57682 has since replaced the fade on the prompt with a 4-line clamp; this PR keeps that.

Changes

• Thin ticks. Each tick is a 1px hairline, 8px long at rest, with at least 3px of gap. When more turns exist than fit at a 4px pitch, the rail shows an even sample that keeps the first and latest turns, so it never merges into a bar. A visible turn without its own tick marks the nearest one.
• No bulge. Only ticks within 16px of the pointer lengthen, to at most 16px. The hovered tick is the brightest, and the turns on screen stay marked (12px, brighter).
• Instant. The preview appears on the first frame the pointer is on the rail, with the prompt already filled in. The 100ms open delay is gone. An unloaded turn's reply is still read only after the pointer rests on it for 150ms, the same 20-message read as before. That read now also fills the replies of the older turns it covers, so the previews near the pointer are usually ready with no extra request.
• Load cost. The big-session audit measured 998 full user rows (22.6 MB, 1.5 s) loaded up front on HOME. This PR doesn't change that load. Requests per hover are back to beta's: one 20-message read after a rest, none during a sweep. Previews can't be lazy yet, because a tick needs its turn ID and the only list of turn IDs is the full user-row list. Fixing that needs the server outline projection the audit proposes, which is out of scope here.
• Teaching. Until the rail has been clicked once, the preview ends with a quiet "Click to jump to this message". The flag is stored globally.

Proof (headless mocked app, dark, 1200×760, real time; before is beta)

The clip shows a long session (200 turns), then a short one (5 turns), hovering up and down and clicking a middle tick and the bottom tick.

A prompt longer than three lines, before and after:

• Per frame: I logged the card's computed opacity and text on every animation frame after the first pointer event on the rail. With this change, the card is at full opacity with its prompt on the first painted frame. On beta it took 12 to 19 frames, depending on the run.
• Keepers: the four navigator keepers pass on a built app, three in timeline-history.spec.ts and one in settings.spec.ts.

Performance

session-timeline-benchmark streaming, with 320 history turns, 160 deltas and a 30× CPU throttle. The benchmark fixture had the rail turned on for this run; the setting is off by default. Two rounds on Studio, alternating beta, this head, and this head with the rail off as a control. Medians:

With the rail mounted, streaming costs the same as with it off; there is no regression. An earlier, noisier run on a loaded Pro, before rebasing onto #57682, pointed the same way: beta 78 s and this PR 33 s, with the rail off at 41 s.

LOC: code +100/−50 (turn-navigator.tsx), plus one English string. No test changes: the keepers cover the rail's contract. Sampling only takes effect at sizes those fixtures don't reach, so the proof above covers it.