fix(lint): say the audio overlap warning is about a shared Studio lane - #7700

Context: I've been using HyperFrames every day for the past two weeks to make Korean Shorts and long-form videos, and it's been great to work with. This PR is one of a batch of fixes for things I ran into along the way, so you'll see several PRs from me at once — sorry for the pile-up, and thanks for your patience. Each one is reproduced on current main, independent of the others, and can be reviewed, merged or closed on its own.

What

duplicate_audio_track keeps the same detection and severity, with new wording. The message now says that both clips play whatever their track, and that the overlap is two clips sharing one Studio lane. The hint says that giving one clip its own data-track-index does not change the mix, and that a leftover duplicate should be removed or moved. docs/reference/lint-rules.mdx says the same.

before  ⚠ duplicate_audio_track: Multiple audible <audio>/<video> elements on track 6 overlap (assets/sfx/whoosh_a.wav at 5.13-5.83s, assets/sfx/land_a.wav at 5.79-6.13s). This causes layered audio playback.
          Fix: Use non-overlapping time windows or different track indices.
after   ⚠ duplicate_audio_track: Audible clips overlap on Studio track 6: assets/sfx/whoosh_a.wav at 5.13-5.83s and assets/sfx/land_a.wav at 5.79-6.13s. Both play at once whatever their track (the render mixes every audible clip; data-track-index only picks the Studio lane), and Studio draws them over each other in that lane.
          Fix: If both should sound (a whoosh into a hit), give one its own data-track-index; the mix does not change. If one is a leftover duplicate, remove it or move it so the windows do not overlap.

Why

I placed a whoosh that runs into a landing hit on the same SFX track, with the overlap on purpose. The warning said this "causes layered audio playback" and suggested a different track index. The docs say the opposite about the attribute. html-schema.mdx: "browser editor timeline lane, display only. The render never reads it and it does not prevent overlap". data-attributes.mdx: "the render ignores it". The code agrees with the docs:

• engine/src/services/audioMixer.ts gives every audible clip its own amix input and never reads a track.
• core/src/runtime/timeline.ts uses data-track-index only to place a clip on a Studio row ("Track index is display-only; render never reads it").

Measured: I rendered the repro twice with hyperframes render -q draft on main, once with both SFX on track 6 and once with the hit on track 7. The decoded audio is identical (ffmpeg … -f s16le | md5 → 0fd325c3f923bd7ae273e71779c15afc both times), and lint is quiet on the second. So the old hint silences the warning without changing what is heard, and "causes layered audio" describes the time overlap, which happens on any track. What a same-lane overlap does cause is in Studio: clips in a row are positioned by start and duration (TimelineClip.tsx), so the two bars overlap in that lane. The rule's other purpose, catching a duplicated sound (the scaffold collision that #299 added it for), is still worth flagging, so detection and severity stay the same.

Related work

• fix(lint): name the clip without data-duration in the audio overlap hint #7386 (open, by another contributor) changes this rule's fixHint for clips without data-duration. It touches the lines next to these and will conflict textually. Whichever lands second takes the other's wording, and the two do not overlap in intent.
• fix(lint): back-to-back audio clips no longer count as overlapping after float rounding #5837 and fix(lint): place each scene's audio at its host's start in the audio overlap check #6005 changed detection (float rounding, scene offsets). This PR does not touch detection.
• No issue or PR covers the wording. I searched "duplicate_audio_track", "audio same track", "data-track-index" and "track-index audio overlap".

How

• packages/lint/src/project.ts: new message and fixHint strings. The windows are formatted as before.
• docs/reference/lint-rules.mdx: the duplicate_audio_track entry says the same as the message.

Test plan

• Unit (packages/lint/src/project.test.ts): says both clips still play, since the track index only picks the Studio lane checks the windows, Both play at once whatever their track, and give one its own data-track-index; the mix does not change. On main (affa03b6) with the fix stashed it fails (expected 'Multiple audible <audio>/<video> elem…' to contain …). With the fix, packages/lint passes 1310 tests and packages/cli lintProject.test.ts passes 78.
• Real CLI, hyperframes lint on the repro (whoosh_a.wav at 5.13 s for 0.7 s and land_a.wav at 5.79 s for 0.34 s, both data-track-index="6"): the before and after output is shown above.
• Render check (main): both variants, as described under Why.

Gates: oxlint and oxfmt are clean. fallow audit --base origin/main passes in the lefthook pre-commit. The comment ratchet and comment citations pass, and the lefthook typecheck passes.