Allow naming API keys

[Dawsson]

Summary

Allow users to assign human-readable names to API keys so they can tell which key belongs to which server, integration, or environment.

Credit to Zoriot for the report.

Problem

When a user has multiple API keys, it is hard to identify which key is used where if keys are only shown by token prefix, creation date, or generic metadata. This makes key rotation and cleanup riskier because users may not know which live server or integration depends on a key.

Proposed behavior

• Let users provide a name when creating an API key.
• Show the name anywhere API keys are listed or managed.
• Allow renaming an existing key without rotating it.
• Keep existing key creation working with a sensible default name when none is provided.

Examples

• Survival production server
• Test server
• Discord bot integration
• Local development

Implementation notes

• Store the name with the API key record or metadata, depending on the current auth/key model.
• Avoid showing full key values after creation.
• Include created date, last used date if available, and key prefix alongside the name so users can safely identify old keys.
• Validate length and trim whitespace to avoid messy key lists.