cycle: security drift detection

[lex00]

Detect repos that have fallen out of the required security posture and correct or alert. Continuous (scheduled sweep + webhook on relevant changes). Reuses the security-feature cycle's desired-state; this is the detect-and-remediate loop. Document the alert-vs-auto-correct policy toggle.

How (cold-handoff): copy the template at src/cycles/branch-protection.ts (read it + src/cycles/README.md). Implement the Cycle interface from src/reconcile/runner.ts (fetchLive/buildDesired/apply receive orgLogin — use it for API paths). Extend src/config/types.ts (all optional — selective-by-omission). Auth src/auth/app-client.ts; diff src/reconcile/diff.ts; guardrails src/reconcile/guardrails.ts. Register in src/cli/registry.ts. Apply = read-modify-write (preserve undeclared live fields); charge the rate budget. Verify via the runner with a mock-client test; tsc clean; tests green.

[lex00]

Closing as covered by #13 (per roadmap decision).

Drift detection and remediation are already first-class via the security-features cycle's run mode — no separate cycle needed:

• Alert / detect — github-warden reconcile --cycles security-features --mode dry-run reports every repo that has fallen out of the declared security posture (the change-set plan is the drift), and the report subcommand (cycle: compliance reporting (aggregator) #19) aggregates it.
• Auto-correct — --mode apply remediates the same drift.

A distinct security-drift cycle would reuse #13's exact desired-state and re-emit the same repo-security entries, double-counting when both run. The meaningful "alert vs auto-correct" choice is the existing dry-run/apply toggle, scoped per run (or per --cycles). If a per-repo/per-feature alertOnly policy is wanted later, it belongs as a flag on RepoSecurityConfig (#13), not a separate cycle — tracked as a follow-up if needed.