admin: consume api.plugins + api.serverInfo (phase-2 step 1)

Retrofit the operator console onto the two shipped seams, same as
dashboard/:
- Auto-discovers every sibling via api.plugins (#610) — the hand-fed
  config.plugins inventory is gone, drift impossible. config.probes now
  only refines individual rows ({ probe?, expect?, kind?, description?,
  adminPage? } by id); admin filters ITSELF out of the roster by prefix.
- Reaches the host via api.serverInfo() (#601) — no config.loopbackUrl.
  Origin (loopback + display baseUrl) resolved per request.

Result: admin needs NO required config, so it's loadable from the CLI
like dashboard —  boots and
serves (open, no pod stats). Verified live on published 0.0.219.

Still re-declared: podsRoot (the api mediates no data-root access) and
the operator gate (adminAgents — no api.isOperator yet); both documented,
both graceful when absent. NOT_POSSIBLE swaps the now-shipped api.plugins
row for the 'gated by default' (api.isOperator) gap.

serve.js drops the shared INVENTORY array (both consoles auto-discover
now); compose.test.js + serve.js admin configs updated. Full suite
385/385.

Author: melvincarvalho

admin/README.md

@@ -34,28 +34,29 @@ const fastify = createServer({
       config: { loopbackUrl: `http://127.0.0.1:${PORT}` } },
 
     { id: 'admin', module: 'plugins/admin/plugin.js', prefix: '/admin',
-      config: {
-        loopbackUrl: `http://127.0.0.1:${PORT}`,   // required (no api.serverInfo)
-        baseUrl: PUBLIC_URL,                        // optional, shown on the page
-        podsRoot: PODS,                             // optional → pod/storage stats
+      config: {                                     // all optional
+        podsRoot: PODS,                             // → pod/storage stats
         // Who is an operator? The api has no answer, so this plugin invents
         // one: an agent-id allowlist. Omit it and the page serves OPEN
         // (loud warn at activate).
         adminAgents: ['https://pod.example/alice/profile/card.jsonld#me'],
-        // A HAND-COPIED duplicate of the list above — no api.plugins
-        // registry to read (#463/#464); the two lists drift silently.
-        plugins: [
-          { id: 'rss',     prefix: '/feed',    description: 'Atom/RSS feeds',
-            probe: '/feed/atom', expect: [400] },
-          { id: 'metrics', prefix: '/metrics', description: 'healthz + Prometheus',
-            probe: '/metrics/healthz', expect: [200], adminPage: '/metrics/metrics' },
-          { id: 'admin',   prefix: '/admin',   description: 'this page' },
-        ],
+        // The plugin list is auto-discovered via api.plugins (#610) — no
+        // hand-copied inventory. `probes` only *refines* individual rows
+        // (the roster carries no health hints):
+        probes: {
+          rss:     { probe: '/feed/atom', expect: [400], description: 'Atom/RSS feeds' },
+          metrics: { probe: '/metrics/healthz', expect: [200], description: 'healthz + Prometheus', adminPage: '/metrics/metrics' },
+        },
       } },
   ],
 });
 ```
 
+Or from the CLI — since admin needs no required config, it loads via
+`--plugin` (open, no pod stats): `jss start --plugin ./admin/plugin.js@/admin`
+alongside other plugins. Add `podsRoot`/`adminAgents` via a config file to
+enable stats and gate it.
+
 - `GET /admin/` — the page (server-side rendered from a live snapshot, so
   `curl` shows real content; an inline script re-polls every ~10s — when
   guarded, append `#token=<bearer>` to the URL so the poller can authenticate).
@@ -88,17 +89,19 @@ with its seam. **Meta**: "3 declared — 2 up, 0 degraded, 0 down, 1 unprobed
 
 The headline: **how much of a wp-admin/Nextcloud-style admin can the plugin
 api express today?** Answer: most of the *read* side, none of the *write*
-side — and every read pillar leans on operator-repeated config. Pillar by
-pillar:
+side. Two read pillars that used to lean on operator-repeated config now run
+on **shipped seams** — the inventory on `api.plugins` (#610) and the origin on
+`api.serverInfo` (#601) — so what's still re-declared is `podsRoot` and the
+operator gate. Pillar by pillar:
 
 | wp-admin pillar | what this plugin does today | the seam that would close the gap |
 |---|---|---|
-| **Plugin inventory** | renders a hand-copied `config.plugins` list; drifts silently from the real `createServer` list (add a plugin and forget the admin entry → it never appears; remove one → it keeps probing) | `api.plugins → [{ id, prefix, module }]` — the #463/#464 app-registry; the loader already holds exactly this data |
+| **Plugin inventory** | ✅ auto-discovered via `api.plugins` (#610) — no hand-copied list, no drift | closed. The roster is `{ id, prefix, module }` with no health hints, so ws endpoints / odd prefixes still want a `config.probes` refinement; an optional per-entry `health`/`probe` hint would close that residual too |
 | **Install / marketplace** | nothing — architecturally impossible; shown in the "not possible yet" strip | a package source + runtime install (#200 marketplace); would also need the loader to activate entries after boot |
 | **Enable / disable** | nothing — the loader activates at boot only; `deactivate()` exists in the plugin contract but nothing calls it at runtime | runtime `activate()`/`deactivate()` on the loader, driven by an authorized surface |
 | **Settings panels** | links to a per-plugin `adminPage` path the operator declares — each plugin hand-rolls its own page and this one merely points at it | a contribute-a-panel affordance (a plugin registers a settings fragment/route with the admin surface); today there is no gated hook or registration point for it |
 | **Health / status** | ✅ the strongest pillar: host liveness + per-plugin anonymous loopback probes, live per request, `expect`/`ws` semantics from `dashboard/` | mostly closed already; per-plugin *self-reported* health (`health: () => …` on a registry entry) would beat anonymous probing |
-| **Users / storage** | ✅ if the operator repeats `podsRoot`: pod count, du-style recursive size (capped at 50k entries, truncation reported, realpath'd root, symlinks never followed, contents never read), newest pod mtime | the api doesn't mediate any filesystem access — `podsRoot` re-declares what the host already knows (cousin of `api.serverInfo`); an `api.storage.stats()` or accounts enumeration would do this honestly |
+| **Users / storage** | ✅ if the operator repeats `podsRoot`: pod count, du-style recursive size (capped at 50k entries, truncation reported, realpath'd root, symlinks never followed, contents never read), newest pod mtime | the api doesn't mediate any filesystem access — `podsRoot` re-declares what the host already knows; an `api.storage.stats()` / data-root accessor would do this honestly. (The origin repetition this used to share is gone — `api.serverInfo` shipped.) |
 | **Log viewer** | nothing — `api.log` is write-only | an `api.log` tailing/reading seam (ring buffer or stream); until then "recent logs" can't exist on any plugin page |
 | **Auth / roles** | invents an operator concept from scratch: `config.adminAgents`, an agent-id allowlist checked via `api.auth.getAgent`; without it the surface is OPEN behind a warn | an operator/role concept in the api. Today every ops plugin invents its own admin auth — `metrics/` a shared token, `terminal/` a token, this one an agent allowlist — three plugins, three incompatible answers to "who is an operator?" |
 
@@ -111,14 +114,14 @@ Beyond the table:
    host clearly has one (whoever writes `createServer`'s config). An
    `api.isOperator(agent)` (or an `operators: [...]` server option plugins
    can read) would let every ops surface in this repo share one answer.
-2. **The pods stats are a config-repetition, not an api capability.** The
-   plugin can count users and measure storage *only because* the operator
-   passed the same `root` path to both `createServer` and this plugin's
-   config — the api itself mediates no storage introspection. Same shape as
-   `api.serverInfo` (the origin repeated in ~17 configs) and the same shape
-   as the inventory (the plugins list repeated): the whole read side of this
-   admin page is the operator telling the plugin what the host already knows,
-   three different ways.
+2. **Pod stats are the last config-repetition standing.** The plugin can
+   count users and measure storage *only because* the operator passed the same
+   `root` path to both `createServer` and this plugin's config — the api
+   mediates no storage introspection. This used to be one of *three* things
+   the operator re-declared (origin, plugin list, data root); the first two
+   shipped (`api.serverInfo`, `api.plugins`) and admin now consumes them, so
+   the read side is down to this one. An `api.storage.stats()` / data-root
+   accessor would close it.
 3. **A guarded plugin page has no session story.** Core's UI has its own
    login; a plugin page can't ride it — the only credential a plugin can
    check is what arrives on the request, so the browser poller has to shuttle
@@ -137,18 +140,21 @@ Beyond the table:
 5. **Composition worked.** This plugin is `dashboard/`'s probes +
    `metrics/`'s healthz idea + `nip05/`'s podsRoot scan + `shortlink/`'s
    `getAgent` guard in one page, with no new primitive needed — evidence
-   that the api's *read-side* vocabulary is genuinely composable. What it
-   could not compose away is any of the four repeated-config findings above.
+   that the api's *read-side* vocabulary is genuinely composable. Two of the
+   repeated-config findings it once carried are now closed (it consumes
+   `api.plugins` and `api.serverInfo`); `podsRoot` and the operator gate
+   remain.
 
 ## Test
 
 ```
 node --test --test-concurrency=1 admin/test.js
 ```
 
-Validation throws first (missing `loopbackUrl`, external probe URL,
-self-probe recursion — before the long-lived boot; the `DATA_ROOT` footgun),
-then one JSS with admin + rss + metrics, `podsRoot` at the server root and
+Validation throws first (external probe URL, self-probe recursion — before
+the long-lived boot; the `DATA_ROOT` footgun), then one JSS with admin + rss
++ metrics auto-discovered (no hand-fed list, no `loopbackUrl`), `podsRoot` at
+the server root and
 `adminAgents` set to a pod minted via `/.pods` + `/idp/credentials`:
 anonymous → 401, second pod's bearer → 403, admin bearer → the full page
 (plugin ids, server-side-rendered pods count, the not-possible strip) and