[FEATURE] last-known dynamic rules survive a restart during a SaaS outage #91

Value this delivers

A guard-core process restarted while the Guard SaaS is unreachable comes back up with the last dynamic rules it applied, instead of silently running base config until the SaaS recovers.

The job you are trying to get done

DynamicRuleManager holds current_rules in memory only. A SaaS outage mid-run is survivable (the update loop logs the failure and retries), but a restart during the outage loses every dynamic rule (emergency mode, IP lists, rate-limit overrides, cloud blocks) until the first successful fetch. The 2026-09-01 Cloudflare outage in front of the SaaS made this concrete.

How you work around it today

There is no workaround inside guard-core: an operator has to re-create the rules as static SecurityConfig fields and redeploy.

Example usage

config = SecurityConfig(
    enable_dynamic_rules=True,
    enable_redis=True,
    dynamic_rules_cache_path="/var/lib/myapp/guard-dynamic-rules.json",
)

Nothing else changes: Redis holds the snapshot whenever a redis handler is present, the file is the opt-in second store.

Additional context

Persist on every successful apply and hydrate once at initialize_agent, before the update loop starts, Redis first then the file, through the normal apply path so snapshot/restore bookkeeping stays consistent. An expired snapshot is discarded and base config runs. An unknown schema version or a malformed payload is discarded with an error logged, never applied in degraded form. The first successful fetch supersedes the hydrated rules through the existing version check.