Close registry gate 7 with owner-approved refresh mechanism

docs/plans/2026-09-03_auth-provider-harness-registry.md

@@ -355,8 +355,9 @@ token. Generated files are disposable derivatives of the registry.
 host service refreshes central OAuth records and rematerializes affected seats;
 launch-time ensure is the final fail-closed gate. OAuth refresh mechanics must
 reuse pi's implementation where possible rather than reimplement provider
-protocols; the exact noninteractive refresh trigger is an implementation
-investigation and acceptance gate.
+protocols; the exact noninteractive refresh trigger is resolved by
+investigation PI-REFRESH-ROCKO-1 (docs/plans/reviews/2026-09-10_pi0851-refresh-investigation.md):
+`pi auth check --provider <p>`, owner-approved 2026-09-10.
 
 ## CLI contract (target `mosaic` surface)
 
@@ -454,6 +455,11 @@ No named accounts currently exist, so migration is state-free:
 - Changing runtime choice regenerates atomically; failed generation preserves
   previous files and records refusal.
 - OAuth central refresh rematerializes affected seats; agents never authenticate.
+Refresh driver (owner, 2026-09-10): the periodic host service invokes
+`pi auth check --provider <p>` per provider — noninteractive, refresh-if-
+expiring (5-minute default window), no credential output. `print-api-key`/
+`print-bearer-token` must not be used by the service because they print
+credential material to stdout.
 - `harness: pi` resolves; unregistered/unsupported harness refuses.
 - Harness detection records recognized compatible executables without reading
   harness homes; incompatible/ambiguous detections refuse availability.
@@ -488,11 +494,15 @@ No named accounts currently exist, so migration is state-free:
 6. **RESOLVED (owner, 2026-09-10):** forked sessions pin the original account
    in immutable session metadata; unpinned relaunches materialize the current
    profile default; selection applies between executions, never mid-session.
-7. **PARTIALLY RESOLVED (owner, 2026-09-10):** the pin moves to pi 0.85.1
-   (exact). A bounded read-only investigation of the 0.85.1 package will
-   determine the supported noninteractive OAuth refresh path; owner approves
-   the mechanism from those findings before implementation. Refresh stays
-   host-side, fail-closed, no token exposure or duplication.
+7. **RESOLVED (owner, 2026-09-10):** the pin moves to pi 0.85.1 (exact).
+   PI-REFRESH-ROCKO-1 (read-only, package identity verified) established that
+   0.85.1 supports noninteractive host-side OAuth refresh via one HTTPS POST
+   using the stored refresh token, no browser, rewriting auth.json in place
+   under an exclusive lock (pre-existing since 0.83.0/0.84.1). Owner selected
+   mechanism (a): the periodic host service runs `pi auth check --provider <p>`
+   — refresh-if-expiring with no token output. `print-*` commands are excluded
+   because they emit credential material on stdout. Launch-time ensure remains
+   the final fail-closed gate. No token exposure or duplication.
 8. **RESOLVED (owner, 2026-09-10):** local Ollama routes via `host-gateway`
    (`http://host.docker.internal:11434/v1`). Remote Ollama supports http and
    https; plain http requires an explicit per-provider `allowInsecureTransport:
@@ -509,5 +519,6 @@ No named accounts currently exist, so migration is state-free:
     cost. Revisit a separate protected registry root only if re-login pain
     proves real (would be a canon change).
 
-Remaining open item before implementation: gate 7's 0.85.1 refresh investigation
-findings and the owner's approval of the refresh mechanism it proposes.
+Remaining open item before implementation: none. All review gates are
+owner-resolved. Implementation itself still requires a separately chartered
+and reviewed increment (author, reviewer, allowed paths, suites, rollback).