feat: runtime allowed-agent registration via admin API

[zippy]

First half of #13: a progenitor (or any allowed agent) can now be registered at runtime instead of editing allowed_agents in the config and redeploying — no more dependency loop between the progenitor node and the joining service.

curl -X POST https://join.example.com/v1/admin/allowed-agents \
  -H "Authorization: Bearer $JOINING_ADMIN_SECRET" \
  -d '{"agent_key": "uhCAk...", "label": "acme-net progenitor"}'

• New AllowedAgentStore (memory / sqlite / Cloudflare KV; backend follows session.store). agent_allow_list accepts agents from the static config list OR the store — existing deployments are unaffected.
• Admin routes POST/GET/DELETE /v1/admin/allowed-agents, bearer-authenticated by the new agent_registration.admin_secret config; mounted only when configured. Mirrors the dynamic linker registration pattern.
• The admin bearer middlewares (this one and the existing linker one) are now scoped to their own path families — the previous /v1/admin/* wildcard on the linker middleware would have 403'd the new routes whenever both admin secrets were configured. src/routes/admin-linkers.ts is touched for exactly this reason, with a combined-admin regression test.

Operational notes:

• Node-only out of the box: the bundled Cloudflare worker entry does not wire a KvAllowedAgentStore yet; Workers deployments must construct one in their worker entry (same pre-existing gap as the linker admin routes).
• Unregistering prevents future joins only — it does not end in-flight sessions or revoke already-joined agents (reconnect does not consult the allow list; revocation remains hc_auth_approval's job).
• sqlite deployments using agent_allow_list will create allowed-agents.db next to the sessions db on upgrade.
• Registration only affects joins when agent_allow_list is in auth_methods; the server warns at startup otherwise.