docs(plan): specify harness declaration + centralized auth/provider registry (#49)

Design only; implementation blocked pending owner review.

- agent.json: one harness identifier (pi first), resolved through a
  versioned adapter/harness manifest; reusable settingsProfile reference
- central data-root registry: providers, accounts (metadata + secret
  credential split), reusable settings profiles, audited runtime selection
- per-seat pi auth.json/models.json mechanically generated and atomically
  activated; no seat/provider registration ceremony
- mixed oauth/api-key accounts supported centrally; one active account per
  provider per pi materialization
- host-side centralized OAuth login/refresh; agents never authenticate
- local/remote Ollama modeled as endpoint providers, not accounts
- target mosaic auth/provider/agent settings CLI; secrets never on argv
- migration, fail-closed acceptance suites, and ten explicit review gates

CURRENT.md points only to spec review. Suites 24/15/90/14/17 + verify
green; unslop clean.

BUILD-LOG.md

@@ -581,3 +581,36 @@ unified CLI) is owner-gated.
 Suites 24/15/90/14/17 + verify green. Default harness usage is untouched
 by design; all mosaic-managed credentials live inside the governed data
 root.
+
+## Phase 25: harness/provider/auth registry specification (#49)
+
+- Design-only phase; no implementation authorized. Draft:
+  `docs/plans/2026-09-03_auth-provider-harness-registry.md`.
+- Agent harness is specified in agent.json as one scalar identifier
+  (`harness: "pi"` initially), resolved through a versioned harness
+  manifest/adapter rather than a permanent hard-coded enum. Existing v1
+  seats migrate with a loud pi default; no CLI harness override in phase 1.
+- Central registry separates providers, accounts, reusable settings
+  profiles, runtime seat selection, and generated harness files. A seat
+  references one reusable profile; it is not registered with each provider.
+- Multiple OAuth/API accounts for one provider may be centrally authorized;
+  pi materializes exactly one active account per provider. Runtime selection
+  is audited data-root state; generated auth.json/models.json are disposable
+  per-seat derivatives.
+- OAuth login/refresh is host-side and centralized; agents never enroll or
+  own refresh tokens. Exact noninteractive pi refresh mechanics remain a
+  required implementation investigation.
+- Local and remote Ollama are endpoint-provider records materialized into
+  per-seat models.json, independently scoped from authentication accounts.
+- Target mosaic CLI covers auth account lifecycle, provider lifecycle,
+  refresh/ensure, reusable settings profiles, and seat selection. Secret
+  material is never accepted on argv.
+- Spec includes registry paths/schemas, naming/perms, fail-closed launch
+  materialization, migration from M19, acceptance suites, and ten explicit
+  owner review gates (including reset/backup semantics and encryption at
+  rest).
+
+## Result (spec draft)
+
+Spec is ready for owner/conductor review; CURRENT.md points only to that
+review. Implementation remains blocked until all ten gates are resolved.