SSO-gated install: bootstrap any host without a shared token

[ExtraToast]

What to build

An SSO-gated way to bootstrap the estate agent setup on any host, so getting a
new machine to parity is a login rather than a token pasted from somewhere.

Today the install path is a curl at knowledge-api carrying
KB_BEARER_TOKEN — a long-lived shared secret in ~/.claude.json on every
machine that ever ran it, which is exactly what the knowledge retirement is
trying to end. The public asset host replaces the transport for content that
is not secret, but it deliberately has no identity: it serves the same bytes
to anyone.

What is missing is a per-host, per-user step for the parts that are
secret: the memory server's API key, the Overleaf session cookie, and
whatever the GitHub MCP server needs. Those cannot live on a public asset
host, and they should not be a shared token either.

The estate already has the pieces: auth-api issues OIDC, several services run
their own client (outline, hermes, grafana), and
DOWNSTREAM_CLIENT_PERMISSIONS maps a client to a ServicePermission. So an
install endpoint behind SSO can mint short-lived per-host credentials and hand
back a config the setup script consumes.

Design questions this ticket has to answer, not assume:

• Where the endpoint lives — a new service, or a route on an existing one.
• Whether the flow is a device-code style grant (a fresh host has no browser
  session yet) or a copy-paste of a short-lived token from a logged-in
  browser.
• What it hands back: env exports the script reads, or a written config file.
• What a revocation looks like when a laptop is lost, which the current
  shared bearer token cannot express at all.

Acceptance criteria

• A new host completes install by authenticating against auth-api, with
  no pre-shared secret.
• Credentials issued are per-host and revocable individually, verified by
  revoking one and watching it stop working.
• No long-lived shared token is written to disk by the install path.
• setup-workstation.sh consumes the result without a second manual step.

Children

• Repair or report the failing github MCP server:
  Repair or report the failing github MCP server #48 (moved here from
  Epic: fix what setup-workstation.sh leaves broken #44 on 2026-09-14 — the 400 is a credential problem, not a script defect)

Blocked by

• Superset installer, so there is one thing to authenticate: Make setup-workstation.sh a true superset and retire install.sh #40

[ExtraToast]

The concrete credential list, from a real run

A run on a fresh-ish host establishes exactly which secrets this ticket has
to deliver. Everything else in setup-workstation.sh now works without one:

Credential	Consumer	State on that host
OPENROUTER_API_KEY	model access for the estate's agents and the memory platform's extraction	not distributed to workstations at all
OVERLEAF_SESSION	the overleaf MCP server (overleaf_session2 cookie)	unset, so the server was correctly skipped
memory API key	the memory MCP server	server not registered yet; key does not exist
GitHub token	plugin:github:github	present but malformed — fails with HTTP 400: Authorization header is badly formatted

The Overleaf skip is worth being precise about: that is the script behaving
correctly, not a defect. It is tracked here because the fix is credential
distribution, not a change to the script.

What this changes about the shape

Two of the four are not estate-issued shared secrets:

• OVERLEAF_SESSION is a browser session cookie, so it expires and is
  per-person. Handing it out from a central store means handing out a
  short-lived artifact and re-issuing it on every expiry — worth deciding
  whether it is issued at all, or whether the host runs olcli auth once and
  the script simply detects it.
• The GitHub credential is owned by a plugin, not by the registry, so
  this ticket can supply it but cannot wire it; see the separate ticket for
  identifying what that plugin actually expects.

OPENROUTER_API_KEY is the one that genuinely wants per-host issuance and
revocation: it is a spending credential, it is currently in Vault for
in-cluster consumers only, and a laptop copy that cannot be revoked
individually is the failure mode to avoid.

Additional acceptance criteria

• OPENROUTER_API_KEY reaches a new host without a shared long-lived
  token on disk, and revoking that host's grant stops it working —
  demonstrated by revoking one.
• The memory API key is issued the same way once the memory server exists.
• The decision on OVERLEAF_SESSION is recorded: centrally issued, or
  established once per host with olcli auth and merely detected.
• setup-workstation.sh consumes whatever this delivers with no second
  manual step, and its summary stops listing these as missing.