feat: real drift history + detect repeated AZ-STOR-002 regressions as one campaign

What problem does this solve?

api/routes/drift.py::get_drift() only compares the latest scan against the previous one and
reports ADDED/REMOVED. A REMOVED finding is ambiguous — fixed, resource deleted, or just not
observed this scan are all indistinguishable today. That ambiguity makes it impossible to reliably
detect a recurring misconfiguration (e.g. four separate AZ-STOR-002 findings across production
storage accounts) as one process-level campaign instead of four unrelated tickets.

Describe the solution

Part A — drift history:

• Persist security-relevant state changes per (rule_id, resource_id) across scans, not just a
  two-scan diff.
• Distinguish REMOVED into FIXED (resource still present, now passing), DELETED (resource no
  longer in inventory), and NOT_OBSERVED (resource not covered by this scan's collection).
• Record a detector/schema version alongside each change. Document a retention window — seeded
  changes should remain queryable past Azure's own 14-day Resource Graph Change Analysis window.

Part B — campaign detector, built on Part A:

• Deterministic grouping: same rule ID, same resource scope (e.g. production tag), within a
  bounded time window → one campaign record with a timeline and evidence-quality indicator.
• Ship a clean-control fixture proving the detector does NOT fire on unrelated findings that don't
  share rule/scope/window.
• Recommend the preventive control (pipeline guardrail / Azure Policy) as campaign output instead
  of separate remediation tickets per finding.
• Scope the demo to exactly this one case: AZ-STOR-002 recurrence.

Alternatives considered

Build generic cross-rule correlation from day one — rejected as too broad for a first demo; prove
the deterministic, explainable case first.

Additional context

Depends on issue 1 (rule evaluation persistence).

Start with api/routes/drift.py::get_drift() and review issue 1, which this work depends on. Define the persisted history and outcome distinctions for AZ-STOR-002, then scope the demo to its recurring findings. Done includes a clean-control fixture showing unrelated rule, scope, or time-window findings do not form a campaign.