fix : refresh token error

[foucblg]

Description

Summary

Fix authentication failures occurring after access token expiration.

Titan previously failed to renew expired access tokens, causing authenticated API requests to return credential validation errors and forcing users to log in again.

Issues/PR dependencies

Issues to be resolved

Required PRs

The related Hyperion change must return 401 Unauthorized when an access token expires so Titan can trigger the refresh flow.

Changes Made

• Read the refresh token from secure storage before renewal
• Persist rotated refresh tokens before continuing
• Serialize concurrent refresh attempts
• Update the Riverpod authentication state after a successful refresh
• Retry failed requests with a valid Bearer authorization header
• Remove the unused and broken authorization-code exchange method
• Prevent duplicate OAuth callbacks on web
• Delete locally stored refresh tokens when definitively rejected
• Clear the authentication state properly on logout

Additional Notes

Refresh token rotation requires every newly issued refresh token to be persisted reliably. Reusing an older rotated token may cause Hyperion to revoke the user's active Titan sessions.

Manual testing

• Logged in successfully on web
• Reloaded the page and remained authenticated
• Forced access token expiration after 15 seconds
• Confirmed that only one refresh request was issued
• Confirmed that authenticated requests succeeded after renewal

Classification

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 🔨 Refactor (non-breaking change that neither fixes a bug nor adds a feature)
• 🔧 Infra CI/CD (changes to configs of workflows)
• 💥 BREAKING CHANGE (fix or feature that require a new minimal version of the front-end)
• 😶‍🌫️ No impact for the end-users

Impact & Scope

• Core functionality changes
• Single module changes
• Multiple modules changes
• Other: ...

Testing

• 1. Tested this locally
• 2. Added/modified tests that pass the CI (or tested in a downstream fork)
• 3. Tested in a local client using a pre-prod backend
• 0. Untestable (exceptionally), will be tested in prod directly

Documentation

• Updated the docs accordingly
• // Comments
• No documentation needed