Gate token publication on persistence; OAuth timeout; scoped mint (parity with wefunder-ruby review) - #2

Reviewed head 7005bd6. The store-only failure path now retains and retries the rotated set, and the scoped installation mint is correct. Three issues remain.

1. [P2] Keep the rotated set pending until the persistence callback succeeds. Both TokenManager and AsyncTokenManager clear pending and publish current before invoking/awaiting on_token_refresh; only store.save is caught. With callback-only database persistence, a blocked callback permits another API call to use the fresh token before it is durable. If the callback raises, later calls continue using that token without retrying the callback. This leaves the original failure in a supported persistence path. Wait for all configured persistence hooks before publication, retain the rotated set on either failure, and add sync/async callback barrier, failure, and retry coverage.

2. [P2] Propagate timeout through refresh, re-mint, and code exchange. The sync constructor and async constructor do not pass timeout into their token managers or recovery re-mint closures. A client configured with timeout=11 (or None) uses that setting for the initial mint/API request but falls back to 30 for automatic refresh or re-mint after a 401. The new timeout parameter is also omitted when exchange_code forwards the request, including the async path. Carry it through those calls and add sync/async transport-recorder tests for expired-token refresh, 401 re-mint, and code exchange. The existing new timeout test only covers initial mint plus a successful API call.

3. [P2] Bind mark_persisted to the exact token set that was saved. The sync acknowledgment and async acknowledgment blindly publish whichever set is currently pending. Using public wf.token_manager: refresh rotates r1→r2 and save fails; caller A retains error.tokens and starts an out-of-band save. Another caller retries persistence successfully via get_access_token, then calls refresh again, rotating r2→r3 whose save fails. A’s delayed save of r2 completes and calls mark_persisted, which publishes pending r3 even though only r2 was saved. The next request can use undurable r3 and restart recovers consumed r2. Accept an expected token set/generation and compare it under the lock. Add a deterministic public-API test proving a stale r2 acknowledgment leaves r3 pending and unused.

Validation was read-only source and existing CI-log inspection; the described public call sequences were not executed locally. CI run 36964292828 passed Python 3.11/3.12/3.13 jobs and generated-code sync; the Python 3.12 log records 155 passing tests. The tested PR merge tree matches this head. Live sandbox e2e was skipped. No live API calls, credentials, local tests, or CI reruns were used.

Re-reviewed head fbf7876. All three P2 findings from my prior review are resolved, with no remaining actionable findings.

Both sync and async managers now complete store/callback persistence before publishing, retain pending tokens on failure, and retry persistence. Timeout is forwarded through the previously missing manager, re-mint, and code-exchange calls. mark_persisted validates the saved token pair under the lock, so an old acknowledgment cannot publish a newer pending set.

CI run 37036496520 passed Python 3.11/3.12/3.13 and generated-code sync, with 162 passing tests. The tested PR merge tree matches this exact head. Live sandbox e2e was skipped.

Validation was source and existing CI-log review; no local tests or live API calls were run. The re-mint timeout fix was verified in source: the timeout test does not actually force a re-mint, so I am not claiming executed coverage of that recovery path.