docs(smoke): drop the #2132 references now that the issue is closed

#2132 was closed without the investigation going anywhere, so every
'pending #2132' pointer in the tree was about to send a reader to a
closed issue whose own diagnosis had already been retracted.

The docs now say what is actually known, and nothing more: the two App
smokes fail under Playwright's WebKit for unidentified reasons; it does
not reproduce in real Safari; an isolated repro of the suspected
mechanism did not reproduce it under Playwright's WebKit either; and
chasing it further was judged not worth the effort. A reader hitting it
locally is told to treat it as unexplained rather than as a defect.

The matrix decision is unchanged and never depended on the cause — the
engine fails, so it is not gated.

No behavior change.

Signed-off-by: cliffhall <cliff@futurescale.com>

AGENTS.md

@@ -920,8 +920,8 @@ Everything about the selection lives in **`scripts/lib/headless-browser.mjs`**
 - **A launch failure names the engine that failed** and its `npx playwright install --with-deps <engine>`. Naming `chromium` while WebKit was the missing one sends the reader to install a browser they already have.
 - **CI runs Chromium in the `build` job's `npm run smoke` and every other gated engine in a `Sandbox smokes (<engine>)` matrix job** — today that matrix is `[firefox]` alone (see the WebKit bullet below). It sets `fail-fast: false` so that once it holds more than one engine, a failure in one cannot hide a failure in another. Chromium is deliberately _not_ in that matrix — `build`'s `npm run smoke` is exactly the local `npm run ci` path and already covers it, and matrixing `build` itself would triple validate, the coverage gate, two verify gates and Storybook to gain three browser smokes. Both `publish` jobs `needs` the matrix, so a release cannot ship past a non-Chromium failure.
 - **`pack:verify` stays pinned to Chromium**, passing it explicitly rather than reading `SMOKE_BROWSER`. It is a _packaging_ check; the engine question belongs where the sandbox is under test, and pinning it also means it can't be pointed at an engine its npm script never installed.
-- **WebKit is deliberately out of the CI matrix for now, and `continue-on-error` is not the answer.** The two App smokes fail there — [#2132](https://github.com/modelcontextprotocol/inspector/issues/2132), by a mechanism that is **not yet identified**: the first diagnosis was retracted when an isolated repro failed to reproduce it, and the failure stage varies between runs. Adding `webkit` to the matrix is a one-word diff once that is resolved; until then an engine is either green in CI or absent from it, because a job allowed to fail reports coverage nobody is held to.
-- ⚠️ **A red WebKit run is not a Safari indictment, for the same reason a green one is not a Safari guarantee.** #2132 was first written up as a Safari bug on the strength of a Playwright-WebKit failure alone; a manual check in Safari did not reproduce it. The caveat below cuts both ways, and only one direction of it was applied. **Reproduce in the real browser before claiming user impact in one** — the divergence between Playwright's WebKit build and Safari is largest in exactly the layer (networking) where that bug lives.
+- **WebKit is deliberately out of the CI matrix, and `continue-on-error` is not the answer.** The two App smokes fail under it for reasons nobody has identified — the failure stage even varies between runs — and the investigation was dropped as not worth the effort once it became clear it does not reproduce in real Safari, and that an isolated repro of the suspected mechanism did not reproduce it under Playwright's WebKit either. Adding `webkit` to the matrix is a one-word diff if someone ever does chase it down; until then an engine is either green in CI or absent from it, because a job allowed to fail reports coverage nobody is held to.
+- ⚠️ **A red WebKit run is not a Safari indictment, for the same reason a green one is not a Safari guarantee.** That failure was first written up as a Safari bug on the strength of a Playwright-WebKit run alone; a manual check in Safari did not reproduce it, and neither did an isolated repro of the mechanism it was blamed on. The caveat below cuts both ways, and only one direction of it was applied. **Reproduce in the real browser before claiming user impact in one** — the divergence between Playwright's WebKit build and Safari is largest in exactly the layer (networking) where that bug lives.
 - ⚠️ **Playwright's WebKit is a WebKit build, not Safari.** Close enough to catch engine-level CSP and iframe divergence; not close enough to certify Safari. Don't write, in a doc or a PR description, that a green run means Safari works.
 
 ### Build output is never a gate target