Thank you for submitting this pull request. We really appreciate you spending the time to work on SurrealDB. 🚀 🎉

What is the motivation?

When an HTTP client's JWT expires, it enters a deadlock: signin() and invalidate() — the operations needed to recover — are also rejected with 401 because the auth middleware (SurrealAuth) validates the Bearer token on all incoming requests before the endpoint handler runs.

The SDK automatically attaches the Authorization: Bearer <token> header on every request, including recovery calls. The client has no way to obtain a fresh JWT without creating a brand-new connection (bypassing the stale Bearer header).

The deadlock flow:

1. Client signs in via HTTP → receives JWT with expiry
2. JWT expires
3. Client calls signin() with valid credentials
4. SDK attaches the expired JWT as Authorization: Bearer <expired>
5. Middleware: expired token → 401 → signin handler never runs
6. Client is stuck

WebSocket is unaffected — WS auth is per-RPC-method, not middleware-based.

Historical context:

• Bug: Expired token is working #3543 reported the opposite bug: expired tokens were silently accepted as valid
• Implement session expiration #3561 fixed that by adding expiry checks — but the fix is too strict, blocking recovery endpoints as well
• This PR finds the middle ground: expired ≠ valid, but expired ≠ block everything

What does this change do?

In check_auth() (surrealdb/server/src/ntw/auth.rs), when Bearer token validation returns ExpiredToken, the middleware now treats it as equivalent to no token — the request proceeds with an unauthenticated (anonymous) session. The endpoint handler then decides what to do:

• /signin: receives anonymous session + credentials from body → verifies → issues new JWT ✓
• /sql and other protected endpoints: anonymous session → permissions error (not 401) ✓
• /invalidate: clears the (already empty) session → succeeds ✓

This is not a security downgrade:

• An expired token provides zero security value
• The anonymous session is identical to not sending any Authorization header at all
• All endpoints enforce permissions based on the session's auth level, not the presence of a Bearer header
• Invalid tokens (bad signature, wrong claims, etc.) still return 401 as before

Uses the existing is_expired_token_error() helper from surrealdb_core::iam.

What is your testing strategy?

New integration test expired_jwt_does_not_block_signin in tests/http_integration.rs with three scenarios:

1. Signin with expired Bearer — POST /signin with expired JWT in Authorization header → must return 200 (not 401)
2. SQL with expired Bearer — POST /sql with expired JWT → must not return 401 at middleware level (handler decides permissions)
3. Full recovery flow — sign in normally, then re-signin carrying an expired token → must succeed (reproduces the exact production deadlock)

All existing tests pass. Fork CI results: 22f/surrealdb#2

• ✅ HTTP / WebSocket / CLI integration tests
• ✅ clippy, format, docs, revision
• ✅ KVS engines (mem, rocksdb, surrealkv), Rust SDK (all engines)
• ✅ SurrealQL tests (rocksdb, surrealkv, tikv)
• ⚠️ SurrealQL tests (mem) — pre-existing flaky failure in access/record/variables.surql (same on upstream main)

Is this related to any issues?

• Fixes Bug: HTTP clients with expired JWT cannot signin or invalidate (auth deadlock) #7195
• Related: Bug: Expired token is working #3543 (expired tokens accepted — the original bug)
• Related: Implement session expiration #3561 (session expiration fix — introduced the deadlock)

Does this change need documentation?

• No documentation needed

Does this change make any alterations to environment variables or CLI commands?

• No changes made to env vars

Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines