Download-signing secret no longer falls back to a hardcoded value

Metbcy/mike removes a hardcoded `"dev-secret"` fallback in the HMAC signing path for `/download/:token` URLs. Without a real secret configured, the backend now refuses to start rather than silently accepting forged tokens.

The upstream codebase had a secret resolution chain for signing download tokens that ended with a hardcoded "dev-secret" string. Because the repo is public, any deployment missing both the dedicated download-signing variable and the Supabase secret would operate with a known key - attackers could forge valid tokens for arbitrary R2 object paths.

The fix is a fail-fast: the secret resolver throws on first use if no real value is configured. The error message includes openssl rand -hex 32 as the suggested remediation command so operators know immediately what to do. The example env file gets the download-signing variable added with a note that it should be distinct from the Supabase key - a documentation gap that previously made it possible to deploy the service without knowing the variable existed.

The change flips the default posture from "insecure but operational" to "won't run without a real key." This was tracked as issue #7 in the fork and merged about a week after it was opened.