[feat]: add schedule report log persistence

[not-meet]

Description

Adds the persistence layer for the scheduled spam-report feature: storing
the active schedule, in-progress setup drafts, and the flag/admin-action
logs the daily report will summarize.

Changes

4 persistence layers were added

AdminActionLogStore

• Logs admin moderation actions (e.g. warn/mute/ban) against a user, writing to two parallel records: a per-day bucket (antispam-action-day:{date}) capped at MAX_DAILY_ACTIONS with a truncated flag, and a rolling per-user "recent actions" list capped at MAX_RECENT_ACTIONS (FIFO via shift()).
• Exposes reads by user (getByUser), by single day (getActionsForDay), and aggregated across a date range (getActionsSince, built on daysBetween).
• Both fetch paths filter out malformed/legacy records (r.action !== undefined) as a lightweight schema guard.

FlagLogStore

• Logs individual spam-flag events, aggregating them into a per-user, per-day DailyFlagSummary (flag count, trigger/action tallies, room list capped at MAX_ROOMS_PER_SUMMARY) rather than storing raw events per day.
• Separately maintains a rolling "recent events" list per user (MAX_RECENT_EVENTS, FIFO), similar to the admin action store.
• Provides day-level (getDailySummariesForDay) and range-level (getDailySummariesSince) reads, again using daysBetween to fan out across day-keyed associations.

ScheduleDraftStorage

• Persists an in-progress scheduling draft per admin user (keyed by user + fixed antispam-schedule-draft scope) while they're stepping through the setup modal.
• Supports two draft stages via a discriminated union (confirm with the draft payload, or delete for a pending removal), plus standard save / get / clear.
• No history or capping logic — it's a single overwritable slot per admin.

ScheduleStore

• Holds the single active daily-report schedule (global MISC association, not per-user), including lastReportSentAt used by ScheduledReporter to determine the report window.
• markSent does a read-modify-write to bump lastReportSentAt without disturbing other fields.
• replace/clear round out basic CRUD for enabling/disabling or reconfiguring the schedule.

NOTE -
Known limitation: AdminActionLogStore.log and FlagLogStore.log do read-modify-write against a shared doc, and Apps-Engine's persistence API has no atomic increment/CAS — so concurrent writes to the same user/day can race and clobber each other.

For AdminActionLogStore, exposure is minimal (human-triggered, low frequency). FlagLogStore is the one actually worth thinking about, since the detector can fire multiple flags in a burst — a race there could undercount flagCount/trigger tallies in the daily summary. I considered switching it to append-only (one record per flag, no read), but that shifts cost to read time — the daily summary would need to reduce N raw events into a rollup on every report run instead of reading one doc, and FlagLogStore has meaningfully higher volume than admin actions, so that trade isn't obviously a win. Either way, this only affects report accuracy — flag levels, restriction actions, and enforcement are driven by UserStatusStore, not this log. Leaving as a documented limitation for now.