Reject unrecognised DATABASE_URL instead of silent SQLite fallback

[mfw78]

Summary

When DATABASE_URL does not match mysql: or postgresql:, vaultwarden silently treats it as a SQLite file path. Any misconfiguration (typo, quoting issue, garbage value) quietly creates an empty SQLite database instead of erroring. In containerised environments this means data loss on restart, which has bitten me personally and others (#2835, #1910, #860).

The partial fix in #2873 catches some cases by checking the parent directory, but does not help when the path resolves within an existing directory.

The core issue is that SQLite selection is implicit. Database selection for a secrets manager should be explicit, not a fallback. An operator who misconfigures their database URL should get a clear error, not a silent downgrade to a different database engine entirely.

Changes

• DbConnType::from_url now recognises an explicit sqlite: scheme. URLs without any recognised scheme are still accepted as bare-path SQLite for backwards compatibility, but only if the file already exists. Otherwise the process panics with a clear message.
• Default DATABASE_URL changed to sqlite://{data_folder}/db.sqlite3 so new deployments use the explicit scheme.
• backup_sqlite and validate_config updated to handle the sqlite:// prefix.
• .env.template updated accordingly.

Test plan

• Fresh deployment with default config creates database normally
• Existing bare-path DATABASE_URL=data/db.sqlite3 (file exists) still works
• Misconfigured URL (e.g. foobar) panics with a helpful message
• SQLite backup works with sqlite:// prefix
• MySQL and PostgreSQL URLs unaffected

Fixes #7062

[tessus]

May I ask why a panic and not a proper error message and clean exit with a specific error code?

[mfw78]

Good catch, and fair point. The panic was a bit short-sighted on my part; this issue had actually bitten me personally so I was perhaps a touch too eager to make it loud. I've since had a proper look through the codebase and can see the established convention is to use err!() which propagates up through from_config() and gets caught by create_db_pool() with a clean exit(1). That's clearly the right approach.

I've pushed a follow-up commit that swaps the panic! for err!() to bring it in line with how the rest of the config validation works.

[BlackDex]

Just a small text change. But i think that is all, the rest LGTM.