Adopt MCP 2026-07-28 in production and pin untested invariants

[blisspixel]

Production now serves the MCP 2026-07-28 revision, and a sweep pins eight rules that were enforced in code but named by no test.

MCP v2 adoption

Moving the pin is what makes recon reachable from a modern-only client at all: the spec's compatibility matrix says modern client plus legacy server fails, and server/discover, per-request _meta, resultType, and cache hints are all SDK-provided.

A v2 server still answers the legacy initialize handshake, so clients on 2025-11-25 keep working. recon's own gate proves that rather than trusting release notes. 1.28.1 stays the rollback pin and stays blocking, so both generations keep being exercised:

SDK	Result
2.0.0	24/24 checks pass
1.28.1	17 pass, 7 correctly not-applicable

Clearing the blocker: the remote adapter

build_remote_application refused any family but v1, so the previous review stopped here rather than disable a shipped feature. Porting it surfaced a genuine latent bug:

• The read-only allow-list read annotations.readOnlyHint. That attribute does not exist on v2 (it is read_only_hint, with the camelCase form surviving only as a serialization alias). Every tool would have looked non-read-only, so the adapter would have removed all of them and served an empty surface rather than a restricted one.
• Transport options moved from a mutable settings object to keyword arguments on streamable_http_app.

Verified against the real v2 SDK: 22 tools filter to the same 17 read-only tools as before.

The disjoint-spelling problem

This recurs across the whole SDK boundary: outputSchema, inputSchema, mimeType, and the CallToolResult shape (v1 returns a tuple, v2 a model, so unpacking raises). Each is resolved once in sdk_compat and read through the protocol's own spelling.

Evidence that this is right: the generated surface inventory is byte-identical across generations.

Note for anyone touching tool annotations: passing the v2 spelling to v1 does not raise. Pydantic stores it as an unrelated extra attribute and leaves the real hint unset, so a mechanical rename would silently drop every annotation on the rollback pin.

Eight invariants pinned

The shareable_scope defect happened because grep found nothing. Each of these was confirmed by mutation (delete the guard, watch nothing fail) and each new test was verified to fail when the guard is removed:

1. A Google CSE probe failure stays an unavailable channel, never "no CSE configured".
2. A degraded email channel cannot become a weak-email-security posture claim.
3. The same rule on the signal path, a separate copy that could drift.
4. Parent-platform presence does not become a child-product use claim via a TXT token.
5. A dormant provider slug alone does not produce an email security score (it rendered "Email security 0/5", which reads as badly secured rather than not measured).
6. chain_resolve clamps depth (the existing test held vacuously: its mock returned no related domains).
7. The MCP chain depth cap was a literal 3, not the shared MAX_CHAIN_DEPTH so the two copies could drift silently. Depth also scales the aggregate timeout.
8. The result-cache poison table asserted nothing for its entire life. All twelve rows wrote a payload for one domain into another domain's cache file, so the read was rejected on the domain binding before reaching the field under test. Re-keying made all twelve real and immediately caught a range check that had never been exercised. A control row now fails if the table goes vacuous again.

One candidate was rejected after mutation: the per-channel cached-replay guard is pinned, just from a different test file than you would expect.

scripts/check.py passes green locally, as do both compatibility matrices and release_readiness.py.