admin: recompute PR A's copied fact days from raw events before they expire #645

PR A's history copy (copy_daily_snapshot_history, #526) filled user_daily_facts from the legacy snapshot table with every metric column 0, operational state healthy / NULL code, tier unpaid, and data_quality='partial'. On prod those are the days 2026-07-29 → 2026-09-22. Complete facts start 2026-09-23.

After #641 the readers treat partial as unknown, so nothing publishes those zeros (e.g. /groups reports partial, not ready). But at 180 days the rows roll into analytics_daily_rollups (kept indefinitely) still partial, so that period stays unknown for good unless it is recomputed while its raw events exist. Raw events are kept 180 days (RAW_EVENT_RETENTION_DAYS), so the oldest copied day, 2026-07-29, becomes unrecoverable around 2027-01-25.

The daily job will not do it: its recompute sweep looks back only RECOMPUTE_LOOKBACK_DAYS = 6 (daily_facts.py:39).

Proposal: a one-off, throttled recompute of those days through _compute_day, run oldest → newest.

Things to settle first:

• Order matters. facts_step builds each day's segment from the prior 29 fact days (sum_recent_facts), so the first copied days have no real history behind them either.
• facts_step reads current user_activity (list_activity(None)), and operational state and tier come from current configuration. Decide which columns a past-day recompute can honestly rebuild (event- and ledger-derived counts) and which stay partial.

Depends on #641.