fix(selfhost): a missing/unreadable _FILE secret degrades to unset instead of failing the container fast

[JSONbored]

Context

src/selfhost/load-file-secrets.ts:25-35's loadFileSecrets: on a missing/unreadable <NAME>_FILE (e.g. TOKEN_ENCRYPTION_SECRET_FILE, GITHUB_WEBHOOK_SECRET_FILE), the function logs one selfhost_secret_file_unreadable error line and returns — the target env var is left unset and startup proceeds normally. This file's own header comment cites the miner's equivalent behavior (packages/loopover-miner/DEPLOYMENT.md:120-122) as the intended model: "A missing or unreadable GITHUB_TOKEN_FILE fails the container fast... rather than silently proceeding with no credential." The ORB self-host implementation doesn't actually do that for its own high-privilege secrets.

Requirements

• Change loadFileSecrets to fail the container's startup (throw / exit non-zero, matching this codebase's existing fail-fast convention for other unrecoverable startup errors) when a _FILE-designated secret is configured but unreadable, instead of silently leaving it unset.
• Verify this doesn't break a legitimate "secret genuinely not configured at all" case (no _FILE env var set) — this fix targets only "configured but the file read failed," not "intentionally omitted."

Test Coverage Requirements

99%+ Codecov patch coverage; a regression test confirming a configured-but-unreadable _FILE secret now fails startup, and that a genuinely-omitted secret still starts normally.

Deliverables

• A broken secret-file mount fails the container fast instead of silently degrading.
• Regression tests for both the fail-fast and genuinely-omitted cases.

Expected Outcome

A self-host operator's broken Docker secret mount for a high-privilege secret is caught at boot instead of running with a silently-missing credential.

Links & Resources

• src/selfhost/load-file-secrets.ts:25-35
• packages/loopover-miner/DEPLOYMENT.md:120-122 (the model this file's own comment cites)

[linear-code]

JSO-4369