Override switch and peak-hour throttle policy modifiers

[Ryan-Atkinson87]

Implement the two policy modifiers that sit on top of the gating decision: the human override
and the peak-hour throttle.

Spec: §6.5 (Override), §6.7 (Peak-hour throttle).

Acceptance criteria

• Override: a backend flag (surfaced as a UI switch in Phase 6) that lets the human work past the threshold into available credits/overage. When on, it suppresses the hard pause (Hard pause and two-tier automatic resume (reset-known sleep + backoff probe) #34), the cap-stepping (Concurrency cap step-down as usage lever (3 to 2 to 1 to pause) #35), and the peak-hour throttle.
• Override is explicit and visible (exposed in the monitor's state for the UI) and does not persist silently across runs unless deliberately left on.
• Peak-hour throttle: when usage.peak_hour_throttle is true (default), throttle or defer heavy work in the weekday-morning window (~5–11am Pacific, the reported ~1.3–1.5× burn period) unless override is on.
• The peak window uses an injectable clock/timezone so the behaviour is testable and not tied to the host clock.
• Both modifiers compose cleanly with Threshold evaluation and date-sensitive Agent SDK credit meter handling #33/Concurrency cap step-down as usage lever (3 to 2 to 1 to pause) #35 — override short-circuits, throttle defers rather than pauses.
• Unit tests cover: override suppressing pause + cap-step + throttle; throttle active/inactive inside vs outside the peak window; throttle disabled via config.

Depends on: #33
Depends on: #35