fix(opencode): reuse host OAuth transport

[OLDyade]

Summary

• reuse OpenCode’s host-owned OpenAI OAuth transport in MemFlywheel background Agent Loops without reading or copying OAuth tokens
• keep the published @earendil-works/pi-ai@0.82.1 dependency unchanged and adapt the transport entirely inside the OpenCode integration
• preserve provider-owned request limits and surface extraction failures through OpenCode logging

Validation

• pnpm run test — 260 tests passed
• pnpm run format:check
• git diff --check
• real OpenCode 1.17.11 E2E with openai/gpt-5.5 and registry pi-ai@0.82.1:
  • host response completed
  • background extraction wrote typed memory, index, audit, source trace, and cursor
  • a fresh session used OpenCode native read on the memory body and recalled the exact value

Dependency boundary

This PR does not require a pi-ai fork, upstream PR, or unpublished dependency. The fix is fully contained in MemFlywheel.

[FenjuFu]

Read through it — the core goal (reuse OpenCode's host-owned OAuth transport without ever reading or copying the token) is achieved cleanly, and I like that the @earendil-works/pi-ai@0.82.1 dep is untouched and everything is adapted on the MemFlywheel side. CI is fully green including e2e-k8s. Approving.

One thing I want to flag on withProviderFetch, not a blocker but worth confirming:

globalThis.fetch = fetchImpl;
try { return run(); } finally { /* restore */ }

This swaps the global fetch for the synchronous duration of run(). It's correct only under the assumption stated in the comment — that the provider SDK captures fetch while streamSimple synchronously constructs its client. If streamSimple ever deferred the fetch grab to a later microtask, the finally would restore the original before the real network work, and the host transport would be silently bypassed. Two asks:

1. Is that synchronous-capture assumption pinned by the @earendil-works/pi-ai@0.82.1 version, i.e. would a future SDK bump silently break it? A comment noting the version dependency would help the next person.
2. Because it's a global swap, two extraction/dream loops running concurrently could observe each other's fetch during that window. MemFlywheel serializes writes under a lock, so this is probably unreachable today — but if background loops can ever overlap, this is a latent cross-talk. Worth a one-line note on the invariant it relies on.

Neither blocks merge; they're about making the invariant explicit so it doesn't rot on a future dependency bump.