`key_prefix` in the API key list is a prefix of the hash, not of the key

list_api_keys in core/switch_core/gateway/api_keys.py (lines 33-48) sets key_prefix=k.key_hash[:12].

key_hash is sha256(plaintext).hexdigest() (line 60), so the value is 12 hex characters of the digest — not of the key.

The gateway UI renders it in a column headed "Key Prefix" with an ellipsis appended (gateway/src/pages/registration-keys/RegistrationKeysPage.tsx, lines 88-95 and 135-142) and makes it searchable (line 80). An operator holding a key cannot match it against the row: the value is truthfully a hash prefix, but is displayed as though it were the key's opening characters.

Possible fixes

A. Show the real prefix. The plaintext is recoverable — add the existing config: Annotated[SwitchConfig, Depends(get_config)] dependency and use decrypt_token(k.encrypted_key, config.jwt_secret_key)[:12], as reveal_api_key already does at line 82.

B. Rename the field to key_hash_prefix and correct the UI header.

A is friendlier but means a list endpoint decrypts secrets on every call, which may not be wanted. Worth deciding explicitly.

Tests

There is no test file for this router.

Start in core/switch_core/gateway/api_keys.py around list_api_keys and reveal_api_key, then inspect RegistrationKeysPage.tsx where the value is labeled, ellipsized, and searched. Review the existing decryption path and decide whether the API should expose a plaintext prefix or consistently identify a hash prefix. Done means the API, UI wording, search behavior, and regression coverage agree with the chosen semantics.