Correct the live view reason rows and watchdog guidance (#704)

* Correct the media stage bound to connected

* Move the example watchdog above the client's connect budget

The snippet remounted 15s after mount. The client's connect bounds run in
sequence and sum to 23s, so an embedder following the example tore the frame
down before the client could report which stage stalled — including media,
the stage most likely to have stalled.

Also correct the note about KERNEL_CONNECTION_TIMEOUT never firing once
negotiation begins. The media bound stays armed past `checking` until ICE
reaches `connected`, so a connect that stalls in between does report one;
what never emits it is a viewer whose frames stop after it connected.

* Set the example watchdog above the connect budget and deslop the guidance

The example remounts at 35s, above the client's connect bounds, which run in
sequence (transport, signaling, media) and now sum to 28s after
kernel-images#472 settled the media bound at 10s. Below the budget the example
reproduces the bug this page was fixing: the embedder tears the frame down
before the client can name the stage that stalled.

The prose around it says what the timer has to clear and why, since the timer
also covers loading the frame and waking a sleeping browser. The timeout
warning names `completed` alongside `connected`, which is the other way the
media bound clears.

The `media` row now reads "connected or completed ... covers a peer that stalls
after checking", folded in from #698, which this supersedes.

* Keep the media bound at 30s and move the example watchdog above the budget

The media bound stays at its interim ceiling. The stretch through ICE
`connected` is unmeasured in every region, so shortening the default is not
something the probe data supports yet; a region that has the timings lowers it
through the live view proxy's override instead.

With the defaults unchanged, the three bounds sum to 48s rather than 28s, so
the example timer moves to 50s to stay above the budget it has to outlast.

* Apply mason's notes on the watchdog paragraph

The prose said the timer covers waking a browser. It doesn't: the proxy wakes the
browser before the socket opens, so that time is already inside the transport
bound, and only loading the page itself is extra.

The example timer moves to 60s. 50s left 2s over the 48s budget, which is thin
for "leave room above the budget", and a region that raises its bounds moves the
budget past 48s anyway. The earlier terminal events still show the fallback as
soon as they arrive, so this timer only catches a silent stall.

Also contracts "Do not" to "Don't", which the docs style guide asks for.

* Correct the transport and peer reason rows

A socket close at any point before the connect succeeds reports `transport`, not
only one before signaling, and `peer` also covers ICE reaching `failed` or
`closed` and the data channel closing before the connect.

The retry advice follows: remounting repeats a construction or offer throw, but
it can fix an ICE failure, so that case is worth one retry.

Author: robertjamesprior

browsers/live-view.mdx

@@ -107,10 +107,10 @@ Both terminal events carry the same `reason`, so branch on it instead of matchin
 
 | `reason` | Meaning |
 | --- | --- |
-| `transport` | the socket never opened inside its bound, or closed before signaling |
+| `transport` | the socket never opened inside its bound, or closed at any point before the connect succeeded |
 | `signaling` | the socket opened but no offer arrived inside its bound |
-| `media` | a peer exists but ICE never reached `checking` inside its bound |
-| `peer` | peer construction or the remote offer threw |
+| `media` | a peer exists but ICE never reached `connected` or `completed` inside its bound — this covers a peer that stalls after `checking` |
+| `peer` | peer construction or the remote offer threw, ICE reached `failed` or `closed`, or the data channel closed before the connect succeeded |
 | `unsupported` | the browser has no `RTCPeerConnection` |
 | `server` | the server closed the connect |
 
@@ -130,7 +130,7 @@ Both terminal events carry the same `reason`, so branch on it instead of matchin
 
 ### Detecting a viewer that never starts
 
-Gate on `KERNEL_PLAYING`. It fires only once frames actually arrive, so it is the signal that distinguishes a working viewer from one that is still connecting or has silently failed. The terminal events below tell you when the client has stopped trying. Start a timer when you mount the iframe and remount if `KERNEL_PLAYING` has not arrived:
+Gate on `KERNEL_PLAYING`. It fires only once frames actually arrive, so it is the signal that distinguishes a working viewer from one that is still connecting or has silently failed. The terminal events below tell you when the client has stopped trying. Start a timer when you mount the iframe and remount if `KERNEL_PLAYING` has not arrived. The timer has to outlast the client's connect bounds, which run in sequence — transport, then signaling, then media — and sum to 48s by default. If you wait less than that, you'll tear the frame down before it can report a stage that stalled late. The timer also covers loading the frame itself, so leave room above the budget when you set it:
 
 ```typescript Typescript/Javascript
 const iframe = document.querySelector('#kernel-live-view');
@@ -147,7 +147,7 @@ function arm() {
     iframe.src = 'about:blank';
     iframe.src = src;
     arm();
-  }, 15000);
+  }, 60000);
 }
 
 window.addEventListener('message', (event) => {
@@ -161,9 +161,9 @@ window.addEventListener('message', (event) => {
 arm();
 ```
 
-Do not gate on `KERNEL_CONNECTION_TIMEOUT` alone. The watchdog behind it is cleared once negotiation begins, so a connection that stalls after that point never emits it. Log it alongside `KERNEL_PLAYING` to capture the connection state at the moment things stalled.
+Don't gate on `KERNEL_CONNECTION_TIMEOUT` alone. It only covers a connect that is still negotiating: the media bound clears once ICE reaches `connected` or `completed`, and a viewer whose frames stop after it connected never emits one. Log it alongside `KERNEL_PLAYING` to capture the connection state at the moment things stalled.
 
-`KERNEL_CONNECTION_FAILED` and `KERNEL_CONNECTION_TIMEOUT` are both terminal, and a failed connect posts one of them, never both. Whichever arrives, nothing further happens until the iframe reloads. Surface a persistent message rather than remounting blindly: a `peer` or `unsupported` reason is a property of the browser environment, so a remount repeats it, while a `transport` reason is worth one retry.
+`KERNEL_CONNECTION_FAILED` and `KERNEL_CONNECTION_TIMEOUT` are both terminal, and a failed connect posts one of them, never both. Whichever arrives, nothing further happens until the iframe reloads. Surface a persistent message rather than remounting blindly. `unsupported`, and a `peer` reason from peer construction or the remote offer, are properties of the browser environment, so a remount repeats them. A `transport` reason, or a `peer` reason from ICE reaching `failed` or `closed`, can come from the network path instead, so give those one retry.
 
 The client does not retry a connect itself, so whatever `reason` you get is the first failure, and whether to try again is your call.