🐛 fix(desktop): add token refresh retry mechanism (#10575)

* 🐛 fix(desktop): add token refresh retry mechanism

- Add `async-retry` library for exponential backoff retry
- Implement retry logic in RemoteServerConfigCtr.refreshAccessToken()
  - Retries up to 3 times with exponential backoff (1s, 2s, 4s)
  - Distinguishes between retryable (network) and non-retryable (invalid_grant) errors
- Update AuthCtr to only clear tokens for non-retryable errors
  - Transient errors now preserve tokens for retry on next cycle
- Add isNonRetryableError() helper method

This fixes the issue where temporary network problems would cause
users to be logged out and require re-authorization.

Closes LOBE-1368

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* update

* 🐛 fix: treat deterministic failures as non-retryable errors

Add deterministic failures to non-retryable error list:
- 'No refresh token available' - refresh token missing from storage
- 'Remote server is not active or configured' - config invalid/disabled
- 'Missing tokens in refresh response' - server returned incomplete response

These permanent failures now trigger immediate token clearing and
authorizationRequired broadcast instead of infinite retry loop.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* 📝 docs: clarify issue status workflow - use "In Review" after PR creation

- Change workflow to set status to "In Review" when PR is created
- "Done" status should only be set after PR is merged
- Add note about Linear-GitHub integration for auto status update

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* 🐛 fix: add grace period for consumed RefreshToken

When rotateRefreshToken is enabled, the old refresh token is consumed
when a new one is issued. If the client fails to receive/save the new
token (network issues, crashes), the login state is lost.

This adds a 3-minute grace period allowing consumed refresh tokens to
be reused, giving clients a chance to retry the refresh operation.

Changes:
- Add REFRESH_TOKEN_GRACE_PERIOD_SECONDS constant (180s)
- Modify find() to allow RefreshToken reuse within grace period
- Add unit tests for grace period behavior

Closes LOBE-1369

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* 📝 style: translate adapter test descriptions to English

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

CLAUDE.md

@@ -81,17 +81,21 @@ When working with Linear issues:
 1. Complete the implementation for this specific issue
 2. Run type check: `bun run type-check`
 3. Run related tests if applicable
-4. **IMMEDIATELY** update issue status to "Done": `mcp__linear-server__update_issue`
-5. **IMMEDIATELY** add completion comment: `mcp__linear-server__create_comment`
-6. Only then move on to the next issue
+4. Create PR if needed
+5. **IMMEDIATELY** update issue status to **"In Review"** (NOT "Done"): `mcp__linear-server__update_issue`
+6. **IMMEDIATELY** add completion comment: `mcp__linear-server__create_comment`
+7. Only then move on to the next issue
+
+**Note:** Issue status should be set to **"In Review"** when PR is created. The status will be updated to **"Done"** only after the PR is merged (usually handled by Linear-GitHub integration or manually).
 
 **❌ Wrong approach:**
 
 - Complete Issue A → Complete Issue B → Complete Issue C → Update all statuses → Add all comments
+- Mark issue as "Done" immediately after creating PR
 
 **✅ Correct approach:**
 
-- Complete Issue A → Update A status → Add A comment → Complete Issue B → Update B status → Add B comment → ...
+- Complete Issue A → Create PR → Update A status to "In Review" → Add A comment → Complete Issue B → ...
 
 ## Rules Index