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.

Author: robertjamesprior

browsers/live-view.mdx

@@ -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. 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, including waking a browser that has gone to sleep, so leave room above the budget when you set it:
+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();
-  }, 50000);
+  }, 60000);
 }
 
 window.addEventListener('message', (event) => {
@@ -161,7 +161,7 @@ window.addEventListener('message', (event) => {
 arm();
 ```
 
-Do not 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.
+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.