feat(mcp): surface non-2xx navigation status

[Skn0tt]

browser_navigate reports URL, title and a console-error count, but not the HTTP status. So a page that comes back 4xx/5xx looks like a successful navigation - the only hint is the error count, which is noisy (a favicon 404 bumps it just the same) and means the agent has to go read browser_console_messages or enumerate browser_network_requests to find out what actually happened.

This adds a Page status line to the page header, but only when the main document is non-2xx:

- Page URL: http://localhost:8402/locked
- Page Title: Payment Required
- Page status: 402 Payment Required   👈
- Console: 2 errors, 0 warnings

A normal 200 shows nothing extra, so the common case stays quiet. It mirrors the existing Page status: crashed line, and the status is captured from the main-frame navigation response, so it also covers reload and back/forward and clears again once you land on a 2xx.

Nothing new is exposed here - the status was always reachable via the console text or the network list. It's a discoverability fix: promote "the document came back non-2xx" to a first-class fact on the result an agent already reads, instead of something it has to go digging for.

This came out of looking at how HTTP 402 paywalls surface to a browser agent. One related gap I hit but left out of here: browser_route can't scope a route to a single request (no times/once), which matters when you want to attach a one-shot header to exactly the next navigation. That's a separate, generic change - I'll do it in its own PR.

[github-actions]

Test results for "MCP"

7474 passed, 1132 skipped

---

Merge workflow run.

[Skn0tt]

Not following up with another PR, so noting it here: the payment side needs no new tooling, browser_run_code_unsafe covers it fine:

async (page) => {
  await page.route(lockedUrl, route =>
    route.continue({ headers: { ...route.request().headers(), 'X-PAYMENT': signature } }),
    { times: 1 });
  await page.goto(lockedUrl);
}