fix(hub): federation is closed until two hubs have run it

Every MHP route answers a stated 503. `federation.FEDERATION_ENABLED` is the
only thing that decides it, applied as a dependency on the router so the six
routes that exist and any added later are covered by construction — a gate you
have to remember to write in each handler is the shape C6 is the standing
lesson about.

The protocol is not what is wrong with it. What is wrong is that nothing has
ever run it: two hubs have never completed one authenticated request between
them. AV14 was two defects in the same path — an issuer signing with a key
bound before it was loaded, naming itself after the reference deployment
whatever the instance was called, and a verifier naming no audience for the
`aud` the issuer sets, which PyJWT refuses outright. Both stood for a month
behind a green suite, and both were found by reading rather than by running,
because a second implementation of a peer proves the protocol and nothing about
two machines.

Four of the six routes carry no authentication of their own — the MHP token is
the authentication — and two of those write, a directory push and a revocation.
That is the surface being closed until somebody stands up a second hub.

A constant and not a `hub_settings` row, deliberately: a switch in the admin
panel invites an operator to turn on a feature that has never worked between
two machines, where this takes an edit, a deploy, and reading the comment above
it. `/v1/hub/info` reports the state, because the `mhp_version` beside it would
otherwise be a claim the hub does not honour.

The protocol tests open the gate for their own duration and say why; the one
that runs with the flag as it ships asserts all six routes refuse. §7.6 states
the closure, §15.2 carries federation between two hubs as not built.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UMxEQadpzPkYLFf5CYKhpW

0 files changed, 0 insertions, 0 deletions