Missing OAuth authorization flow — plugin cannot obtain its own bot identity

[QiuYi111]

Problem

The plugin supports OAuth tokens (clientId/clientSecret config, token refresh logic, persistToken to Cyrus config) but has no OAuth callback route. This means there is no way for the plugin to obtain its first OAuth token through an authorization flow.

Current Workarounds (all flawed)

1. Borrow from Cyrus config (resolveLinearToken 2nd priority) — tight coupling to Cyrus, not a proper standalone solution
2. Personal API Key — operates as the user identity, not a bot. Comments/status changes appear as the user, not as a dedicated agent. This is a fundamental design issue for any multi-user or team deployment.
3. Manually paste OAuth token — no UX, token expires, defeats the purpose

Expected Behavior

The plugin should be a Linear bot/integration with its own identity, not impersonating the user. This requires:

1. An OAuth callback route (/linear-light/oauth/callback) to complete the authorization flow
2. An init/setup command or page that starts the OAuth flow (redirects to Linear authorize URL)
3. Proper token storage (plugin-local, not Cyrus config)
4. Automatic refresh using clientId/clientSecret (already implemented, just needs the first token)

Severity

Critical — this is an architectural issue that affects the core identity model of the plugin. Without OAuth flow, the plugin cannot operate as a proper bot/integration in Linear.

[QiuYi111]

Additional Context: Linear refresh tokens are single-use

Linear's OAuth refresh tokens are consumed on use — each refresh returns a new refresh token, and the old one is immediately invalidated. This has critical implications:

Current ensureValidToken() is unsafe

The method has zero coalescing — it directly calls fetch(LINEAR_OAUTH_TOKEN_URL) with no guard against concurrent invocations. If multiple requests trigger refresh simultaneously:

1. Request A refreshes → gets new access_token + refresh_token_B (old refresh_token consumed)
2. Request B refreshes with the same old refresh_token → 400 Bad Request
3. All subsequent API calls fail permanently until manual re-auth

This is exactly the bug that was diagnosed in Cyrus (see ceedaragents/cyrus#1059).

persistToken() coupling to Cyrus config is wrong

• Writes to ~/.cyrus/config.json — tight coupling to Cyrus, not standalone
• No file write coalescing or atomicity concerns addressed
• Should have its own token storage (e.g., ~/.openclaw/plugins/linear-light/token.json)

Required fixes

1. OAuth callback route (original issue)
2. Token refresh coalescing — static map + cooldown like Cyrus fix
3. Plugin-local token storage — not Cyrus config
4. Atomic token writes — write-then-rename pattern