fix(web): report the last probe outcome when detached readiness times out - #2668

Thanks, the diagnostic is the right idea and the functional claim reproduces at this head. Two things before it can land:

1. On a 200 /api/meta response that fails the space or pid match, the last-probe text embeds the full JSON.stringify of both fields with no length cap. Whatever answers the bound port can therefore make the timeout error arbitrarily large, and launchDetachedWeb rethrows that whole message to the terminal and into the failure path that also appends the log tail. We reproduced a 200 KB error from a 200 KB space value. Please summarize a mismatched body with bounded fields (truncate the space to a short fixed width, stringify the pid only when it is a short number or string) and cap the whole last-probe string to a few hundred bytes before it is appended.
2. The operator pages are not updated. docs/watch-a-mesh.md and the cotal web --detach section of docs/cli.md should explain the new suffix: the probe URL, an HTTP refusal status, a transport error, and a mismatched space or pid. The URL is the bound probe address, not the browser launch URL.

We will re-review the next push.

Both points are done. In the last-probe text the space is cut to 40 characters and the pid to 20, and the whole text is capped at 300 UTF-8 bytes. Both operator pages now describe the suffix exactly as summarizeProbeField and capProbeText behave. I also merged the latest main into the branch (one conflict in web.ts, resolved by keeping the probe change on top of the new session header), and typecheck, tests and the docs checks pass.

Thanks for the push. The cap and the operator pages from the first round are in, and the functional claim still reproduces at the merge-base and is fixed at this head for HTTP status, transport refusal, malformed JSON and mismatched metadata. One thing is left:

1. capProbeText (implementations/web/src/web.ts around line 1372) slices the buffer at PROBE_TEXT_MAX_BYTES (300) and then appends the three-dot marker, so the marker is outside the budget. A local 200 /api/meta answer whose space is U+0001 repeated 40 times and pid U+0001 repeated 20 times drives the JSON escaping past the limit: at this head the text after ; last probe is 303 bytes and the whole suffix 316. That contradicts the hard 300-byte promise in the changeset and in both operator pages (docs/cli.md line 1965, docs/watch-a-mesh.md line 130). The existing detach.smoke.ts only checks the total message stays under 500 bytes, so it does not see this. Reserve the marker's bytes before slicing at a valid UTF-8 boundary, say whether the documented budget covers the prefix, and assert the documented maximum in the existing smoke with an escaped or multibyte boundary input rather than a new suite.

We will re-review the next push.

Thanks for this, @drakeo338. A detached dashboard that misses its readiness deadline now reports the last probe URL and what that probe returned, with the message size capped. Two independent reviews approved the final head, and it typechecked cleanly against current main before we squash-merged it.