#9040: fix(security): throw on config validation failure instead of returning empty config

## Security Issue Fixes #5052 When `loadConfig()` failed validation (e.g., due to invalid plugin references), it returned `{}` instead of propagating the error. This caused all security settings to fall back to permissive defaults: - `dmPolicy` defaulted to `"pairing"` — any sender could get a pairing code - `allowFrom` was ignored — allowlist protection bypassed - `groupPolicy` was ignored — group restrictions bypassed ## Root Cause ```typescript } catch (err) { if (error?.code === "INVALID_CONFIG") { return {}; // ← Security settings wiped } return {}; // ← Also on read errors } ``` ## Fix Throw the error instead of returning empty config: ```typescript } catch (err) { if (error?.code === "INVALID_CONFIG") { // SECURITY: Do not return {} on validation failure. throw err; } // SECURITY: Do not return {} on read failure either. throw err; } ``` ## Impact **BREAKING CHANGE**: `loadConfig()` now throws on validation failure instead of returning `{}`. - Gateway startup already handles this correctly (refuses to start with invalid config) - Runtime callers must now handle the exception - This is intentional — operating with no security is worse than crashing ## Compatibility with #9036 This pairs well with PR #9036 (systemd restart limits). If config is invalid: 1. Gateway throws and refuses to start 2. Systemd restarts it (up to 5 times in 5 minutes) 3. After hitting the limit, manual intervention required This is the correct fail-closed behavior for a security-critical system.