docs(554): the opt-in's unreachability is about started, not about mount order

"its button renders only before the player has ever mounted" is loose: a channel
switch to a forced channel re-renders the button after a player has mounted for the
previous channel. The load-bearing fact is the one the code comment states — the
button renders only while `started` is false, and the only thing that un-starts the
panel is the channel reset that clears the flag in the same batch.

Refs #554

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV

docs/spa-conventions.md

@@ -667,9 +667,9 @@ channel-preview panel wires it to a "press play" hint whose visibility is the re
 `state === 'starting'` **alone**, so a second clear in `onPlaying` would be a guard no test could
 distinguish. That holds because the panel's paths back to `starting` either clear the flag themselves
 (Retry, a channel change) or cannot be reached while it is set — the forced-preview opt-in re-enters
-`starting` without clearing, but its button renders only before the player has ever mounted, so the
-flag is necessarily false there. The panel never claims the fault fixed itself; the hint mirrors an
-honest, still-not-playing state.
+`starting` without clearing, but its button renders only while the panel has not started, and the
+only thing that un-starts it is the channel reset that clears the flag. The panel never claims the
+fault fixed itself; the hint mirrors an honest, still-not-playing state.
 
 **Resolving a `/iptv/*` src under JWT auth (#552).** Before feeding an `/iptv/*` manifest URL to
 `HlsPlayer`, pass it through `withIptvToken(url)` (`web/src/media/iptvToken.ts`): under a JWT-enabled