fix: make the client-traffic trace answer the question it exists for (#120)

[ifahimreza]

Closes #120

Found by reading a customer's capture of a failing ChatGPT connection, not by reading the code. Three defects, all of which shaped the last two weeks of that thread.

1. The panel recorded its own polling

targets_mcp() was a bare strpos() prefix test, and Saddle_REST_Admin::REST_NAMESPACE is also saddle/v1 — so /saddle/v1/mcp-diagnostics matched, and McpDiagnostics.jsx polls it every 5 seconds while recording.

At MAX_ENTRIES = 25 the ring buffer therefore turned over every ~125 seconds. The capture that arrived spanned 114 seconds and held two real rows among twenty-three of the panel watching itself. The instrument was evicting the evidence it exists to collect.

Matched exactly now (=== $mcp || strpos( $route, $mcp . '/' ) === 0), buffer raised to 100 for margin.

2. The credential scheme was recorded and rendered nowhere

Every row has carried Saddle_Connection::credential_scheme() since the recorder shipped. Neither report()'s format string nor the table printed it.

So the one field that separates "the key was rejected" from "no key arrived" — the same 401, opposite fixes, one is reconnect the app and the other is your host is stripping the Authorization header — was written to the option and shown to nobody. The customer asked us for it by name, after the answer was already sitting in saddle_mcp_trace on his own site.

It is now first on the row, ahead of session and protocol, which are trivia next to it. Paired with an explicit auth: present|absent|unknown, because '' and 'unknown' are different answers and neither is "present".

3. No HTTP method

A row reading Asked for — was ambiguous between a GET, a POST with the wrong content type, and an empty body. Different answers, identical row. method is recorded now.

A test that was passing for the wrong reason

test_a_recorded_request_contains_no_credential() set an Authorization header on a synthetic WP_REST_Request, which populates no $_SERVER — and Saddle_Connection reads $_SERVER deliberately, because the failure this surface exists to diagnose is a host stripping the header before PHP. So the recorder never saw a credential and the "no leak" assertion was vacuous.

The helper now sets both. That is what makes the two new scheme assertions meaningful, and it retroactively proves the original assertion was load-bearing.

Testing

• composer test — 599 tests (was 596), 2003 assertions, 1 pre-existing skip, green
• Each new test verified red without its fix. One of them was not, first time round: the targets_mcp regression passed against the bug, because rest_do_request() never fires rest_post_dispatch and so nothing was written either way. Rewritten to drive the real chain, and it now fails correctly without the fix. Left a comment saying so.
• composer lint — 0 errors (pre-existing warnings only); npm run lint:js clean
• npm run build — bundle rebuilt and committed
• languages/saddle.pot regenerated