fix(auth): prevent OAuth refresh lock races

[graseeel]

What changed

• share one OAuth refresh in flight between proactive expiry checks and reactive 401 recovery
• prevent ENOTACQUIRED/ERELEASED during lock cleanup from replacing an OAuth result that was already determined
• keep unexpected lock-release errors fatal instead of masking them
• add regression coverage for the exact release error and simultaneous refresh paths

Why

A long tool turn can trigger a proactive token check and a server-initiated 401 recovery close together. Those paths previously used separate in-flight guards, so both could acquire or replace the same proper-lockfile target. If their release callbacks completed out of order, the CLI surfaced Lock is not acquired/owned by you and aborted the turn even when the refreshed token had already been persisted.

This change serializes the two refresh paths and treats only the two known stale-ownership cleanup codes as non-fatal. It does not retry the whole agent turn, avoiding duplicate tool side effects.

Validation

• Red/green regression: the exact ENOTACQUIRED test failed before the fix and passes after it
• bun test src/utils/auth.refresh.test.ts src/utils/providerAccounts/store.cross-process.test.ts — 8 pass, 0 fail
• bun run build — passed; CLI and SDK bundles validated
• node dist/cli.mjs --version — 0.15.13 (Verboo Code)
• bun run scripts/pr-intent-scan.ts --base upstream/main — no suspicious additions

Repository-wide validation is not currently green: bun test reported 2697 pass / 137 fail in other suites, and bun run typecheck reports existing generated-surface/type drift. The changed auth files introduce no additional scoped typecheck errors.

No version bump or release is included in this PR.