Filter rules that cannot be loaded never lead to a more lenient decision #836

Goal

If filter rules cannot be loaded, the filter engine never decides more leniently than it would with the rules loaded: nothing runs automatically, and the confirmation dialog says that the rules are unavailable.

Context

• PolicyStore::rules_for(&self, scope) -> Vec<Rule> has no error channel (crates/core/src/filter/engine.rs:47-50).
• SqlitePolicyStore::rules_for (crates/persistence-sqlite/src/policy_store.rs:427-458) logs a database error and returns an empty list. Its own comment states the consequence: the hard blacklist stays active and a missing allow rule correctly yields Confirm, but a user Deny rule is lost while loading fails and degrades to a clickable Confirm; "a visible UI notice … is not wired yet".
• CombinedPolicySource (engine.rs:93-123) merges several PolicySources and skips a failing source with a warn! only. With more than one source, the allow rules of the working sources still apply while the rules of the failing source are missing, so the combined result can be more lenient than all sources together would be. Today production uses the single SQLite source (crates/app-logic/src/state.rs:118, crates/app-shell/src/commands/connect.rs:949), but the type is public and meant for several sources (Spec 0037 §5), and Wiring::policy_sources (crates/app-shell/src/wiring.rs:33, empty in the community wiring) is the extension point for adding them.
• Evaluation: evaluate_explained_inner reads self.store.rules_for(&scope) at engine.rs:396; rules_by_ids (:269) uses it for display; crates/app-shell/src/commands/connect.rs:1613 uses it to list allow rules in the system prompt.
• Codes are mapped to user texts in apps/smart-ssh-community/frontend/src/errorCodes.ts and src/locales/*/common.json (e.g. FILTER_SUDO_PASSWORD_REQUIRES_CONFIRM); the locale parity check covers all languages. Ledger decision entries carry the code (crates/core/src/audit/mod.rs:99-102).
• About 36 PolicyStore implementations exist, almost all test doubles (grep -rn "impl PolicyStore for" crates).

Requirements

• rules_for reports whether the rule set is complete, e.g. -> PolicyRules { rules: Vec<Rule>, unavailable: bool } or PolicySourceResult<Vec<Rule>> plus a partial form for CombinedPolicySource (see Open questions).
• SqlitePolicyStore: a database error yields "unavailable" (no rules), still logged with tracing::error! without rule contents.
• CombinedPolicySource: if any source fails, the result is "unavailable" and contains the Deny and Confirm rules of the working sources but no Allow rule from any source.
• Filter engine, when the rule set is unavailable:
  • never returns AutoExec;
  • a Deny from the remaining rules and the hard blacklist keep winning exactly as today (combine never lowers);
  • otherwise returns Confirm { code: "FILTER_RULES_UNAVAILABLE", reason: … }; the reason says that the filter rules could not be loaded and the command therefore needs confirmation.
  • EvaluationTrace records the check (like the other push_check codes) so the confirmation explanation can show it.
• FILTER_RULES_UNAVAILABLE is added to errorCodes.ts and to every locales/*/common.json with a translation in every locale, as the existing FILTER_* codes have.
• connect.rs:1613 (allow rules in the system prompt) lists no allow rules when the set is unavailable; rules_by_ids behaves as today on the rules it has.
• No Deny from any source may be dropped by this change.
• Comments in new code in English.

Acceptance Criteria

• Test: a failing SQLite store (or a test double that fails) with a command that would match an allow rule → Confirm with code FILTER_RULES_UNAVAILABLE, never AutoExec.
• Test: CombinedPolicySource with source A failing and source B containing a matching Allow rule → Confirm with FILTER_RULES_UNAVAILABLE, never AutoExec.
• Test: same setup, source B containing a matching Deny rule → Deny (the working source's deny still applies).
• Test: hard blacklist hit while rules are unavailable → same decision and code as with rules loaded.
• Counter-check: with both sources healthy, the same allow rule yields AutoExec (the test setup is not trivially failing).
• Test: the ledger entry for a decision made while rules are unavailable carries FILTER_RULES_UNAVAILABLE.
• Locale parity and errorCodes.ts checks pass with the new code; the confirmation dialog shows the new text (frontend test with the code).
• The comment in policy_store.rs:427-441 describes the new behaviour instead of the open gap.
• All existing filter, adversarial and property tests pass.
• Relevant automated tests pass.

Technical Notes

• Security-critical area (filter engine, fail-closed behaviour): read .claude/skills/smart-ssh-coder/references/security-invariants.md (invariants 1, 2) and AGENTS.md. Review priority elevated.
• The change is in FilterEngine evaluation itself: keep it minimal and in its own PR; the precedence chain for loaded rules must be byte-for-byte unchanged (property tests in crates/core/src/filter/property_tests.rs and adversarial_tests.rs must pass unmodified).
• The mutation test exclusion for NoRules::rules_for in .cargo/mutants.toml (last entry) must be updated to the new signature.
• Most of the work in test doubles is mechanical (Vec<Rule> → complete rule set).

Spec impact: update 0002 (§5 policy store, new code), update 0037 (§5 combined sources: failing source drops all allow rules)

Open questions

• Return type. Options: (a) PolicyRules { rules, unavailable } struct; (b) Result<Vec<Rule>, PolicySourceError> for the store plus a separate partial result for the combined source. Recommendation: (a) – one type expresses "partial" for the combined source, and test doubles only need PolicyRules::complete(vec![…]).

Related Work

• Kill surviving mutants in the filter engine: decision priority and combination #487 (mutants in decision priority and combination)