willchen96 gives stored API keys their own lock and key

When a user stores a third-party API key in Mike, that key gets encrypted at rest. Until now the system would, if no purpose-built secret was set, silently fall back to the same master key that guards the database itself. willchen96 has cut those fallbacks out. The encryption now demands its own dedicated secret and refuses to handle stored keys without it, with a startup error that says exactly what's missing.

The point is separation of concerns. Tangling user secrets up with the database master key meant rotating one could put the other at risk, and made it genuinely hard to know which key was protecting what in any given deployment. Anyone running this stack will now have to provision that dedicated secret before the service will store keys at all - a deliberate trade of one-time setup friction for cleaner, safer key rotation down the line.