Scope in-memory API keys to registry URLs

[drernie]

Problem

#5240 isolates authenticated HTTP sessions by registry URL, but API-key authentication remains process-global. After setting a key for registry A, switching to registry B through a registry override creates B's session with A's key. This can cause authentication failures or disclose A's credential to B.

Expected behavior

• Associate each in-memory API key with the resolved registry URL it authenticates to.
• Use a key only when creating a session for that same registry.
• Preserve existing single-registry login_with_api_key() behavior.
• Allow clearing one registry's key without affecting others; logout() may continue clearing all authentication state.
• Cover switching, nesting, and concurrent contexts so API keys never cross registry boundaries.

Follow-up to #5240.

[drernie]

We chose registry-keyed storage rather than an independently context-scoped API key because registry affinity is an authentication invariant: a key is issued by one registry and must never be presented to another. This also matches Quilt3's existing registry-keyed interactive credentials and HTTP-session cache, plus quiltx's per-catalog credential storage.

A separate API-key context would create two ambient values—the registry and the key—that could be scoped or restored independently and become mismatched. A future convenience context manager can still bind the registry/key pair atomically on top of the registry-keyed model.