Custom connector: broker fails in start-auth with zero egress; same URL works in Claude Code, and fronting the origin with Cloudflare fixes it

## Summary

Adding a self-hosted authless MCP server (Streamable HTTP) as a custom connector on claude.ai fails with "Couldn't reach the MCP server". Our edge logs show **zero inbound requests** from Anthropic during every attempt — no initialize, no `/.well-known` probes, nothing at all.

The browser network tab shows `GET /api/organizations/.../mcp/start-auth/...` returning **HTTP 400** with:

```json
{"error_code":"mcp_auth_start_failed","error_visibility":"user_facing"}
```

so the broker fails before dispatching any HTTP request. Same pattern as #214, #227 and #374.

**The useful new datapoint: putting the identical server behind a Cloudflare Worker (`*.workers.dev`) made the connector attach immediately, first try.** Same code, same TLS config, same MCP payloads — only the network path in front of it changed. That points at egress filtering or origin-address selection in the broker rather than anything server-side.

## Server

- Origin: Hetzner VPS, Caddy → uvicorn, valid Let's Encrypt cert, HTTP/1.1 + h2
- MCP Python SDK 1.29.0 (FastMCP), stateless Streamable HTTP, `json_response=true`, authless, secret path segment
- Endpoint shape: `https:////mcp`, protocolVersion 2025-06-18, 4 tools

## Evidence the server is fine

- `initialize` and `tools/list` verified with curl from several networks, correct JSON-RPC responses
- **The exact same URL connects in Claude Code** (`claude mcp add --transport http`), status ✔ Connected, tools callable end-to-end
- Anthropic infrastructure can reach the host: WebFetch from a Claude session retrieves `https:///healthz` without issue
- Full request logging on the proxy shows our own test traffic arriving while connector attempts leave no trace

## Failure references

- `ofid_c657de17c99216c4`
- `ofid_964d98ee5da9139f`
- `ofid_e566e153176f3f64`
- `ofid_3e1478ed1f0fe4a4` (captured directly from the `start-auth` API response)

Org ID and the full URL available privately on request.

## Ruled out

Trailing-slash redirects (endpoint serves both, no 3xx), DNS/AAAA issues (A record only), Host-header validation (transport allows the public host), stale connector state (removed and re-added), TLS/cert problems (verified from multiple vantage points).

## Expected

The broker should at minimum attempt discovery/initialize against the URL — observable in the operator's access logs — and connect an authless Streamable HTTP server that Claude Code already accepts.

## Workaround for anyone else hitting this

Front the origin with a Cloudflare Worker and point the connector at the `workers.dev` URL. A minimal pass-through relay and the full diagnosis are in https://github.com/starkshtlm/kindle-scribe-mcp (see `worker/` and `docs/troubleshooting.md`).

## Environment

claude.ai web (Max plan), Chrome on macOS.