Fix login blocked by transient FalkorDB unavailability

[Copilot]

When FalkorDB is temporarily down, OAuth login enters a broken loop: the api_token cookie is set after OAuth completes, but every /auth-status check fails because the token was never persisted to FalkorDB — causing the login modal to reappear indefinitely.

Approach

Use the existing Starlette signed session cookie as a secure auth fallback when FalkorDB is unreachable. Session data is written at login time and validated against the request's api_token cookie on each request — token mismatch returns unauthenticated, preventing stale-session abuse.

Changes

api/auth/user_management.py

• Add DatabaseUnavailableError to distinguish "DB unreachable" from "token not found" (both previously returned None)
• _get_user_info raises DatabaseUnavailableError instead of swallowing the exception
• Add _validate_from_session(request, api_token) — authenticates from session only when session["api_token"] == api_token
• validate_user catches DatabaseUnavailableError and delegates to _validate_from_session

api/routes/auth.py

• Add _store_session_backup(request, user_data, api_token) helper
• Call it in all three login paths (google_authorized, github_authorized, email_login) after the handler stores credentials
• Clear session backup keys in logout (both GET and POST) to invalidate the fallback on explicit logout

# validate_user now falls back gracefully:
try:
    db_info = await _get_user_info(api_token)
except DatabaseUnavailableError:
    return _validate_from_session(request, api_token)  # uses signed session cookie

tests/test_session_auth_fallback.py

• Unit tests covering: token match/mismatch, empty session, missing session attribute, DB-up vs DB-down paths

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Login shouldn't be blocked by DB connection</issue_title>
<issue_description>Currently if the Database is not available and the user has a connection to a database and the database is not available the login fails and the login module is showed again.

It should pass the stage and only test the connection on query </issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Login shouldn't be blocked by DB connection #494

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Anchel123]

Superseded by #719, which takes a different approach to the same issue (#494).

This PR keeps FalkorDB as the primary check and falls back to the session only when the token query raises. That leaves a gap: if the token is simply absent from the graph — because the login-time write failed during the outage, or because FalkorDB restarted without its data — the query succeeds and returns nothing, so the fallback never fires and the user stays stuck. Every request also still pays a graph round trip just to stay logged in.

#719 inverts it. The browser login becomes a signed session cookie that is never checked against the database, API tokens stay database-backed but are only consulted when a caller supplies one deliberately, and an unreachable store is reported as 503 rather than 401 so clients retry instead of re-authenticating.

Closing in favour of #719. Thanks — the DatabaseUnavailableError idea carried over as AuthBackendUnavailableError.

[Anchel123]

Superseded by #719, which takes the approach described in this PR's discussion: the blocker is auth-status token validation reaching into the Organizations graph, not the external DB connect step.

Linking for traceability — no action needed here.