feat(policy): record mode-dial changes in the drift ledger via log_change

[fu351]

Slice

• Feature / Slice: F10 follow-up — issue Wire the mode dial (doberman mode / setup) through log_change so mode changes hit the ledger #79 (mode dial → append-only ledger)

Closes #79

What this PR does

doberman mode <m> and the setup wizard called config.save_mode() directly — a paranoid → light downgrade recorded nothing. Both user-initiated call sites now route through a shared _apply_mode_change helper that audit-logs via drift.log_change (the scope-enforced, audited-but-not-gated path from #72) before saving:

• Downgrades land as weaken / method="logged" rows in doberman policy-history; upgrades as strengthen.
• No-op (same mode) skips the ledger call — no confusing neutral rows.
• Best-effort by design: a ledger failure prints a warning and the mode change still applies (the dial stays frictionless; the audit is the addition, not a new gate).
• Unknown-mode error behavior unchanged (resolve_mode raises before anything happens).

Test-fixture save_mode calls (6 test files) were deliberately left unwired — not user-initiated.

Tests added (run in CI)

tests/unit/test_mode_ledger.py (4): downgrade→weaken row · upgrade→strengthen row · same-mode records nothing · monkeypatched ledger failure → warning + mode still applied.

Security checklist

• Raise-only: this only ADDS auditing; no gate loosened, no new gate on the dial (per feat(policy): gated enforce/monitor/off change primitives + PolicyDoc.enforcement (F10) #72's deliberate design)
• No secret logged (mode names only; reason is a fixed constant)
• Fails safe: ledger failure cannot block or corrupt the mode change
• lint-imports green

Notes

Pre-existing doc bug spotted (out of scope, not fixed here): README references doberman policy set-mode <mode>, but the actual command is doberman mode <name>.