Make per-purpose secrets mandatory and enforce isolation at boot

bmersereau removes the silent fallbacks that let the download token signing secret and the user API key encryption secret quietly reuse the Supabase service key. Both secrets are now required, must be set explicitly, and must be distinct from each other and from the Supabase key - enforced at startup before the server accepts any traffic.

The enforcement point is a boot-time assertion rather than a lazy check on first use. If either secret is missing, or if either matches the Supabase secret, or if the two match each other, the server throws before it binds to a port. That converts a class of latent misconfiguration from something you'd discover in production into a hard startup failure.

The PR is scoped tightly: the two call sites that read the secrets, the new assertion, its wiring into server startup, and eleven unit tests covering the success and failure paths. Closes four issues (#66, #82, #83, #88).

The migration note is the part to read carefully. Operators relying on the undocumented API_KEYS_ENCRYPTION_SECRET fallback must carry that exact value into the new variable name. Rotating it isn't an option - every stored user API key was encrypted with the derived key, and changing the input breaks decryption for all of them.