Serialize Databricks credential refreshes across host and runner processes

[dbczumar]

Problem

On Aug 19–22, concurrent Omnigent host, runner, and harness processes on one machine refreshed the same Databricks OAuth profile independently. Refresh-token rotation then invalidated another process's refresh token, causing repeated disconnects and requiring databricks auth login.

Expected behavior

All processes on a machine should share one token publication and serialize refresh for each profile/workspace pair. Permanent login failures should stop refresh storms, recover automatically after login, and preserve existing sessions.

Acceptance criteria

• One machine-wide refresh at a time per profile and workspace
• Host, runner, harness, forwarding, policy, MCP, and routing paths use it
• Permanent refresh failure creates a rate-limited recoverable state
• Re-login recovery validates the token against the workspace
• Concurrent-process, crash, timeout, unsafe-file, and reconnect behavior is tested
• A repository guard prevents new direct SDK refresh paths

[github-actions]

🤖 Automated triage

• Bot assessment: Medium impact
• Priority: P2-medium
• Why: Concurrent host and runner processes can invalidate Databricks refresh tokens and interrupt active sessions, but users can generally recover by running databricks auth login, so the session/authentication CUJ is disrupted rather than permanently blocked.

This automated assessment uses the issue content and repository signals. Maintainers can override the priority label.