Custom connector fails with zero requests dispatched to a provably healthy MCP server — "Couldn't register with sign-in service" without ever calling /register

# Custom connector fails with zero requests dispatched to a provably healthy MCP server — backend fabricates "Couldn't register with sign-in service" without ever calling /register

## Summary

Adding a custom connector for a self-hosted MCP server fails instantly on both Claude Desktop and claude.ai web (regular browser). During the failing attempts, **zero HTTP requests of any kind reach the server** (no `/.well-known/*`, no `/register`, no `/mcp`), yet the UI reports "Couldn't register with 's sign-in service" — a DCR failure for a registration that was never attempted. Claude Code CLI connects to the same endpoint and uses all 7 tools throughout, including at the moment of the failing attempts.

This connector **worked until the week of 2026-07-20** and broke with no server-side change (reverting the server to a known-good revision from the working period fails identically).

## Environment

- Server: FastAPI + MCP streamable-http (`stateless=true`), 7 tools, valid schemas (~9.4 KB `tools/list`)
- Endpoint: `https://chad-macbook-m5.taila2d3e.ts.net/mcp` (Tailscale Funnel, valid Let's Encrypt cert)
- Claude Desktop 1.24012.9 (macOS) and claude.ai web in Safari — identical failure
- Claude Code CLI: **works against the same URL throughout**

## Decisive controls (each verified, not inferred)

1. **Zero-traffic browser reproduction (2026-07-25).** Fresh connector name (`AuraBrowser`), added from claude.ai in a regular browser while tailing server access logs. Error toast appeared instantly: "Couldn't register with AuraBrowser's sign-in service… reference: `ofid_4aa6613bdd252141`". Server logs over the same window show only health checks — **no inbound request from Anthropic infrastructure at all**.
2. **Stock reference server fails identically.** A minimal MCP SDK `FastMCP` server with one trivial tool and **no OAuth of any kind**, on the same host behind the same funnel, was rejected with "Couldn't register with RefProbe's sign-in service" — the backend demanded OAuth registration from a server that has none. This exonerates all application code.
3. **Known-good code revert changes nothing.** Reverting the server to the revision running during the months it worked produces the identical failure, with zero requests reaching the server.
4. **Public control succeeds.** `https://mcp.deepwiki.com/mcp` (open, no OAuth, stateless, ordinary registered domain) connects successfully from the same app and account.
5. **Anthropic's fetcher can reach the host.** A cloud-side fetch of `/health` over the same funnel returns 200. The funnel is publicly reachable.
6. **When the flow does progress (manual OAuth Client ID), it dies at token exchange.** With a manually entered client ID the backend called `/authorize`, received a 302 with `code`, `state`, and `iss` (RFC 9207) to `https://claude.ai/api/mcp/auth_callback`, and then **never issued `POST /token`**. Advertising `client_secret_post`/`client_secret_basic` and adding `iss` changed nothing. This matches #215.

## Interpretation

The failure occurs inside the connector broker **before any HTTP dispatch**, and its verdict persists across remove + re-add, fresh connector names, and a fresh URL path on the same host — consistent with the account/URL-keyed cached negative verdict described in #479 and #406, and/or a policy applied to tunnel-provider hostnames (`ts.net` and `trycloudflare.com` are Public Suffix List entries; a `trycloudflare.com` URL also received zero requests). #111 was reportedly resolved via a server-side allowlist exception, which suggests the mechanism exists.

## Flow references (for backend lookup)

Most recent, with confirmed zero inbound traffic: `ofid_4aa6613bdd252141` (2026-07-25, claude.ai web in Safari).

Earlier attempts (2026-07-25, Desktop): `756e7867c44ea1a3`, `9570a730be25a3b4`, `1221b62917aac01c`, `64549b5043b411ff`, `656c63eeb79aaf6b`, `a2b979680cade0c3`, `a438cedbb8690163`, `d7b9a0464824b5e0`, `5f97ec60edf902e2`, `90f4c6bc41d3823a`, `9c32ad931dfea648`, `848d5f2a72423f1a`, `62104572b7943b10`, `937da2ddb4da552c`, `b4db4106bdc6116a`, `9bb640ad42a341fe`.

Error codes observed in `claude.ai-web.log`: `mcp_auth_start_failed`, `mcp_registration_failed`, `"Server not found"` — the last two against a host that demonstrably answers.

## Asks

1. Look up `ofid_4aa6613bdd252141` and state where the broker aborted — no request was dispatched, so the answer is entirely in your logs.
2. Clear any cached negative verdict for this account/URL (per #479) or apply the allowlist exception mechanism referenced in #111.
3. If tunnel-provider hostnames (PSL entries) are now policy-blocked, document it — the current error messages misattribute the failure to the user's server.

## Related

#215, #227, #479, #406, #402, #111, #435, #291