fix(storage): don't query the encryption key registry when storage is off (unblocks backend:dev:saas)

[ConnorYoh]

Description of Changes

Fixes a startup failure introduced by #7155 and reported against task backend:dev:saas.

What goes wrong

StorageProviderConfig.storageEncryptionState(...) is created on every startup, in every profile. When storage.encryption.enabled is false — the default, and what SaaS ships — the || short-circuit evaluates fileEncryptionKeyRepository.count(), a live query against file_encryption_keys:

if (writeEnabled || fileEncryptionKeyRepository.count() > 0) {   // <- always runs when the flag is off

That table only exists if ddl-auto=update managed to create it. When it cannot — permissions on a shared Supabase branch DB, concurrent DDL from several developers, schema ordering — ddl-auto logs and continues, so the situation used to be a warning nobody noticed. Now it is a query that throws during bean creation and takes the whole context down.

Two things make this sting in SaaS specifically: storage.enabled is false there, so before this feature nothing ever touched the table; and hibernate.default_schema=stirling_pdf means the table has to exist in a schema the app may not be able to create in.

There is a second exposure on the request path: suppressDirectDownloads() also counts (60s cached), so even a surviving boot could 500 on downloads.

Fix

• The boot probe runs only when storage.enabled is true, so a deployment that does not use storage never touches the table.
• Registry reads are wrapped. The boot probe degrades to "no keys" rather than propagating; suppressDirectDownloads() fails safe by suppressing rather than issuing a presigned URL it cannot vouch for. Losing the direct-download fast path is recoverable; serving ciphertext is not.

Safety is unchanged, and that is the important part. The decorator is still installed unconditionally, so any blob carrying the SPDFEAR1 magic is still decrypted via lazy materialisation or fails loudly — the eager probe only ever bought earlier master-key verification. A node that can actually serve stored files has storage.enabled on by definition, which is exactly the node the drifted-node protection is for; that test now configures it that way, and a new test pins that the decorator remains installed even with storage off.

Tests — storage-disabled never calls count(); an unreadable registry still boots and still suppresses direct downloads; the decorator stays installed with storage off; storage-enabled still probes. Full proprietary suite green apart from the pre-existing Windows-symlink FolderIdentitiesTest failure, which is environmental and unrelated.

Note on scope: deliberately minimal so it can land quickly. The Aikido findAll() code-quality finding lives in #7173 only (rotateMasterKey does not exist on main), so it is fixed there rather than here. #7173 will be rebased once this merges.

---

Checklist

General

• I have read the Contribution Guidelines
• I have read the Stirling-PDF Developer Guide (if applicable)
• I have read the How to add new languages to Stirling-PDF (if applicable)
• I have performed a self-review of my own code
• My changes generate no new warnings

Documentation

• I have updated relevant docs on Stirling-PDF's doc repo (if functionality has heavily changed)
• I have read the section Add New Translation Tags (for new translation tags only)

Translations (if applicable)

• I ran scripts/counter_translation.py

UI Changes (if applicable)

• Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR)

Testing (if applicable)

• I have run task check to verify linters, typechecks, and tests pass
• I have tested my changes locally. Refer to the Testing Guide for more details.