…tacklok#4198)

* Key upstream token storage on (sessionID, providerName)

Restructure UpstreamTokenStorage so tokens are keyed by
(sessionID, providerName) instead of just sessionID, enabling
multiple upstream providers' tokens to coexist per session.
This is the foundation for multi-upstream IDP support (RFC-0052).

Storage layer:
- UpstreamTokenStorage interface gains providerName param on
  Store/Get and new GetAllUpstreamTokens bulk-read method
- Memory backend uses nested map (sessionID -> providerName -> entry)
  with empty inner map cleanup during eviction
- Redis backend uses per-provider keys (upstream:{sid}:{provider})
  with a session index SET for enumeration and atomic deletion
- PendingAuthorization gains UpstreamProviderName and SessionID
  fields for future multi-leg authorization chains

Service + middleware:
- upstreamtoken.Service.GetValidTokens takes providerName
- upstreamswap.Config gains required ProviderName field
- runner/middleware derives ProviderName from upstream config

Bug fixes from review:
- Fix provider name key mismatch: callback handler now uses the
  upstream's logical name (UpstreamConfig.Name) instead of the
  protocol type (upstream.Type()) for both ProviderID and the
  storage key, matching what the middleware uses to retrieve tokens
- Fix singleflight key collision: include providerName in the
  singleflight dedup key to prevent cross-provider result leaking
- Fix Redis GetAllUpstreamTokens excluding expired tokens (violates
  interface contract that includes expired tokens at bulk-read level)
- Add warn logging for corrupt entries in Redis GetAllUpstreamTokens
- Defensive slice clone in Redis DeleteUpstreamTokens to prevent
  append mutation of the original providerKeys slice
- Add sessionID validation in GetUpstreamTokens for consistency
  with StoreUpstreamTokens
- Populate PendingAuthorization.UpstreamProviderName in authorize
  handler for multi-upstream forward compatibility

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Add backwards-compatible migration for provider ID rename

Existing deployments store upstream tokens under the legacy key
format (upstream:{sessionID}) with ProviderID set to the protocol
type ("oidc"/"oauth2"). The multi-upstream restructuring changed
both the key format and ProviderID to use logical names. Without
migration, upgrading users would lose sessions and get new internal
user IDs.

Upstream token migration (RedisStorage.GetUpstreamTokens):
- On ErrNotFound, fall back to legacy key format
- Patch ProviderID to the logical name before returning so the
  refresher writes to the correct new key (prevents refresh loop)
- Re-store under new key format and delete legacy key
- Preserve ErrExpired semantics for expired legacy tokens

ProviderIdentity migration (UserResolver.ResolveUser):
- Before creating a new user, check legacy provider IDs ("oidc",
  "oauth2") for existing identity records
- If found, create new identity under current provider ID pointing
  to the same internal user, preserving sub claim continuity
- Keep legacy records as defensive fallback (not deleted)
- Handle concurrent migration via ErrAlreadyExists

Both migration paths are idempotent and marked with TODO for
removal after all deployments have migrated.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Add integration tests for upstream token session binding

Verify end-to-end that the callback handler stores upstream tokens
under the correct (sessionID, providerName) key and that the tsid
JWT claim maps to retrievable tokens.

TestIntegration_UpstreamTokenStorage:
- Tokens retrievable by provider name ("default") after full flow
- ProviderID is the logical name, not the protocol type
- Binding fields (UserID, UpstreamSubject, ClientID) populated
- UserID matches JWT sub claim

TestIntegration_RefreshPreservesUpstreamTokenBinding:
- tsid claim preserved across refresh token grant
- Upstream tokens still retrievable after refresh
- ProviderID unchanged after refresh

Infrastructure: expose UpstreamTokenStorage on testServer struct
via srv.IDPTokenStorage() for storage assertions in tests.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Add legacy migration tests and fix expired token migration

Add miniredis unit tests for the legacy upstream token migration
path, verifying:
- Legacy key format tokens are migrated on read (ProviderID patched,
  old key deleted, new key created)
- Expired legacy tokens are migrated with ErrExpired preserved
- New-format keys take priority over legacy keys

The expired token test caught a bug: the migration fallback skipped
expired legacy tokens because getUpstreamTokensFromKey returns
ErrExpired (non-nil), which the guard condition treated as "not
found". Fixed by allowing ErrExpired through the legacy fallback.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Enforce pending.UpstreamProviderName in CallbackHandler.

AuthorizeHandler records which upstream initiated the authorization,
but CallbackHandler ignored it and always used h.upstreamName.
Add a consistency check: if the pending state names a different
provider than the handler serving the callback, reject with a
server_error redirect. This prevents misrouted callbacks from
associating sessions with the wrong provider namespace.

Harden legacy migration against cross-provider attacks.

Identity migration:
- Scope findLegacyProviderIdentity to a single legacy ID derived
  from UpstreamConfig.Type, not a global ["oidc","oauth2"] scan.
  This prevents cross-provider account merge when two upstreams
  share a subject value.
- Propagate transient storage errors instead of swallowing them
  (fail closed rather than creating duplicate users on Redis blip).
- Inject UserResolver into NewHandler as a dependency so Handler
  carries no migration-specific knowledge.

Redis token migration:
- Add isLegacyUpstreamProviderID guard: refuse to migrate tokens
  whose ProviderID is already a logical name, preventing any
  provider from claiming another provider's legacy tokens.
- In practice, the remaining window (protocol-typed tokens claimed
  by first caller) is safe because validateUpstreams() enforces a
  single upstream, and new multi-upstream deployments start fresh
  without legacy keys.

* Fix lint

* Regenerate docs

* Replace inline migration with one-shot bulk startup migration

Move legacy data migration from the read path (GetUpstreamTokens,
ResolveUser) to a single bulk migration that runs at authserver
startup before handlers are constructed.

This eliminates ~100 lines of inline fallback logic, security
guards, and legacy-aware fields from the hot path. The read path
is now a straight key lookup with no branching.

The migration is idempotent, crash-safe (each key independent),
and fails startup if any keys cannot be migrated — since the
request path no longer has inline fallbacks for unmigrated data.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Flatten nested upstream token map in memory storage

Replace map[sessionID]map[providerName]*timedEntry with a flat
map[upstreamKey]*timedEntry using a composite struct key. This
eliminates the empty-inner-map cleanup pattern that was duplicated
in cleanupExpired and DeleteUser — a known footgun when adding
new deletion paths.

The trade-off is O(N) scans in GetAllUpstreamTokens and
DeleteUpstreamTokens instead of O(1) session lookup, which is
acceptable for this dev/test-only storage backend.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Return error from NewHandler instead of panicking on nil resolver

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Clarify Redis key comments for session index set and key prefix

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Add integration tests for legacy data migration against real Redis

Test the one-shot bulk migration against a real Redis Sentinel
cluster via testcontainers, covering: full lifecycle (token key
migration, identity duplication, session index, user:upstream
reverse index, DeleteUser cascade), idempotency, TTL preservation,
empty-store no-op, and new-format key non-interference.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>