forge: external forge accounts live in swarm bao; the agent fetches them itself

An operator now links an agent's external forge account (label, base URL,
token) in the swarm UI. swarm-controller stores it at
swarm/agents/<agent>/forge/<label>. There is no index: the store's
listing of the agent's forge/ directory is the set of accounts.

In the agent, hive-agent-forge-accounts (oneshot + 2-minute timer, as
the agent user, under its own store certificate) lists
swarm/agents/<agent>/forge/ with the `list` #4866 grants an agent on its
own metadata subtree, reads each account, and writes
<state>/forge-<label>-token and forge-<label>.json in the names and shape
hive-forge -f already reads. An empty listing (a 404, which `bao kv list
-format=json` answers with `{}` and an empty stderr) is zero accounts; a
denial or an unreachable store fails the unit. It never deletes: files
for labels not listed, including ones the hive wrote, stay as they are.

Removed: the dashboard FORGES tab (credentials.js/html section and its
CSS), hive-c0re's extra_forges.rs and its routes, priv_client's
extra-forge calls, and hive-priv's WriteAgentExtraForgeAccount /
DeleteAgentExtraForgeAccount with their helpers. The GITHUB tab and
WriteAgentGithubToken stay.

Also: persistence.md's matrix avatar note names the exit-75 restart on a
changed account listing, not the dashboard, as what brings a linked
account up.

Refs #4348

docs/web-ui/dashboard.md

@@ -296,7 +296,7 @@ on the H0M3 hub, same minimal chrome as `/logs.html` (a `← home` back-link
 than `/core.html`'s plain title. Its own esbuild bundle
 (`credentials.js`); no SSE — it reads `/api/state` once for the (shared)
 agent picker and otherwise works off purpose-built endpoints per tab.
-Two sub-tabs:
+One sub-tab:
 
 Link an external matrix account from the swarm UI (`LinkMatrixAccountForm` → swarm-controller). Accounts already linked through the old MATRIX tab keep working until the operator moves them to swarm level.
 
@@ -318,31 +318,7 @@ Provisioning posts `POST /api/github-account` (form-encoded `agent`,
 `application/problem+json` with the message in `detail`. The token is never
 echoed back in either direction.
 
-### FORGES tab
-
-Store a **label + base URL + access token** for an external Forgejo/Gitea/
-Codeberg-compatible forge, per agent. Entirely dashboard-provisioned —
-there is no host-side nix config for this (no `services.hyperhive.
-extraForges` option). The operator creates the token on the external forge
-themselves (however that forge lets them — PAT UI, a teammate with admin,
-whatever) and pastes label/URL/token into the form; hive-c0re never talks
-to the external forge's API and never creates an account there.
-
-The selected agent's stored forges come from `GET /api/extra-forges?
-agent=<name>` → `{ forges: [{ label, base_url }] }`, derived by scanning
-the agent's state dir for `forge-<label>-token` files (mirrors the MATRIX
-tab's filename-scan listing) with `base_url` backfilled from a sibling
-`forge-<label>.json` sidecar. Submitting the add form posts `POST /api/
-extra-forge-account` (form-encoded `agent, label, base_url, token,
-action=add`) → `200 { ok: true }`, which writes both files through the
-same privileged write path as the other tabs. Each row's `remove` button
-opens a themed confirm dialog, then posts the same endpoint with
-`action=remove`, deleting both local files — nothing changes on the
-remote forge. The token is never echoed back in either direction.
-
-A per-forge `hive-forge --forge <label>` CLI selector (to make `hive-forge`
-target one of these accounts instead of the internal forge) is a
-deliberate non-goal of this tab — tracked separately.
+Link an external forge account from the swarm UI (`LinkForgeAccountForm` → swarm-controller); the agent fetches it into the files `hive-forge -f <label>` reads. Accounts already provisioned through the old FORGES tab keep working until the operator links them there.
 
 ## P3RM1SS10NS tab