fix: prevent audible audio interruption during Turbolinks navigation (issues #8, #12)

[adurrr]

Closes #8, Closes #12

Issue #8 — Audio Interruption

Root cause: During Turbolinks navigation, the footer's permanent <audio> element survives and keeps playing. But _applyPositionAndResume() would unconditionally seek (this._audio.currentTime = targetTime) on reconnect, forcing the browser to seek the audio buffer — creating an audible gap/stutter.

Fix: Two changes in PodcastFooter._applyPositionAndResume():

1. Threshold guard on seek — only seek if the computed targetTime differs from current audio time by > 0.5s. Since the audio keeps playing during navigation, currentTime is already within a few hundred ms of the correct position.

2. Guard play() call — only call audio.play() if the audio is actually paused. The footer never pauses in disconnectedCallback, so calling play() on an already-playing element is redundant and can cause a glitch.

Issue #12 — Persistence Review

Reviewed the full persistence layer (both <podcast-player> inline players and <podcast-footer>):

• sessionStorage fallback is sound — footer uses fixed key, inline uses per-instance keys derived from src
• DOM framework markers correctly applied in _persistenceSetup() with idempotency guard
• Inline disconnectedCallback marks paused=true to prevent footer audio theft on return
• Footer disconnectedCallback correctly avoids pausing/clearing audio — enabling uninterrupted playback through navigation
• No structural issues found; the unnecessary seek was the only behavior causing perceptible problems

Tests

• ✅ 80 JS unit tests pass (vitest)
• ✅ 21 E2E tests pass (Playwright, including persistence + Turbolinks)