chore(reliability): add recover() to non-fan-out fire-and-forget goroutines (auth, rate-limiter, GCP token-exchange)

[cristim]

Summary

The fan-out helper just got recover() via #669 / PR #670. Audit of all other goroutine starts surfaced 3 more fire-and-forget goroutines without recover():

File:Line	Purpose	Panic blast radius
internal/auth/service_apikeys.go:279	Async UpdateLastUsed after API-key auth	crashes Lambda mid-request (any path including in-flight purchase)
internal/api/db_rate_limiter.go:137	Async cleanup() of expired rate-limit entries	crashes Lambda mid-request
internal/api/handler_accounts.go:811	GCP ts.Token() with timeout channel	crashes Lambda on account-test requests

Each is LOW likelihood (small DB UPDATE / cleanup / a single library call), but a panic kills the entire Lambda process. Cheap insurance.

Pattern to apply (matches existing internal/api/ri_utilization_cache.go:153):

defer func() {
    if r := recover(); r != nil {
        logging.Warnf("<context>: background goroutine panic: %v", r)
    }
}()

Acceptance criteria

• All 3 goroutines have a deferred recover() at the top
• Each logs via logging.Warnf (these are non-critical paths; Warn is right level)
• No new test required (the existing recover-pattern test at ri_utilization_cache_test.go is sufficient as a precedent)

Cross-references

• fix(execution): FanOutWithConcurrency goroutine has no recover() — purchase panics crash the whole Lambda (P1) #669 / PR fix(execution): recover from panics inside FanOutWithConcurrency goroutines (closes #669) #670 (the fan-out recover() — same defensive pattern)
• fix(purchases): EC2 RI purchase times out under transient AWS SDK retries; Lambda 60s budget blown (P0) #667 (concurrency audit context)