bmersereau tries to stop one secret from guarding two doors

A proposal to make sure the key that encrypts users' stored credentials can't quietly borrow the login-verification secret instead.

In this fork, if the dedicated secret used to encrypt users' saved API keys was missing, the backend silently fell back to reusing the secret that verifies login tokens - one credential doing two unrelated security jobs. bmersereau's fix removed that fallback: the encryption secret now has to be configured on its own, and if it isn't, the system fails loudly instead of quietly running in a weaker state.

The reasoning is clean secret hygiene - a missing setting shouldn't silently degrade into a working-but-weaker configuration that nobody notices in production. The proposal came with fresh tests confirming the shortcut was gone and the dedicated secret genuinely required. It was ultimately closed without being merged, so the change didn't land here, but the intent is a textbook security posture improvement.