fix(auth): mosaic-managed auth lives under the data root, never ~/.pi (#48)

Owner direction: the stack must never impact default harness usage.
Correction to M19 as shipped (nothing had been created in ~/.pi — the
move breaks nothing).

- Mosaic-managed accounts: <dataRoot>/auth/<account>.json, perms 0600
  enforced (loose perms flagged in listings, refused by --auth — mirrors
  gitea-api.sh credential hygiene).
- ~/.pi is read-only to the stack, permanently; the only interaction
  remains the existing read-only container mount of the default
  credential. Recorded as a ROADMAP standing decision.
- auth.sh is now config-driven (data root from config.json, fail closed,
  consistent with every other tool); status reports both sources labeled.
- agent.sh --auth resolution moved after load_config (needs the data
  root); missing/symlinked/non-0600 accounts refuse.
- test-auth.sh: 15 no-Docker cases (accounts-create-nothing, loose-perms
  refusal, invalid-config refusal added). Test-authoring correction
  recorded in BUILD-LOG (fixture-state mismatch caught before running).

Suites 24/15/90/14/17 + verify green.

docs/plans/ROADMAP.md

@@ -17,6 +17,10 @@ and BUILD-LOG phase.
   referenced from AGENTS.md.
 - **Capability restriction becomes progressive and role-based** (M18),
   porting prior Mosaic Stack concepts where they fit the file-based runtime.
+- **The stack never writes to default harness config locations** (owner,
+  2026-09-03, #48): `~/.pi` — and any future harness home — is read-only to
+  Mosaic tooling; the only interaction is the existing read-only credential
+  mount. Mosaic-managed auth lives under the data root (`<dataRoot>/auth/`).
 
 ## M16 — Release self-determination