[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.

[scuciatto]

ScheduleRecord.lastReportSentAt is a non-optional number with no default set anywhere, so the first report run after a schedule is created, before markSent has ever run, sees 0. Running the base-branch daysBetween directly

since=0 -> 20665 days (1970-01-01 … 2026-07-30)
since=undefined -> []
since=NaN -> []

That's a Promise.all of ~20k readByAssociation calls from inside a scheduled job. Suggest clamping the window:

const MAX_REPORT_WINDOW_DAYS = 31;
const days = daysBetween(sinceTimestamp).slice(-MAX_REPORT_WINDOW_DAYS);

…and initializing lastReportSentAt: Date.now() on schedule creation. The silent [] on undefined/NaN is the mirror hazard: a malformed timestamp produces an empty report rather than an error

[not-meet]

Added MAX_REPORT_WINDOW_DAYS = 31 and clamped it exactly as suggested: daysBetween(sinceTimestamp).slice(-MAX_REPORT_WINDOW_DAYS). Applied to both AdminActionLogStore.getActionsSince and FlagLogStore.getDailySummariesSince since they share the same pattern.
Also added a guard that throws on a non-finite sinceTimestamp instead of silently returning [] so a malformed timestamp surfaces as an error rather than a quietly-empty report, per your mirror-hazard note.

[scuciatto]

No retention or cleanup for day-keyed records. On a busy server, this is permanent linear growth in app persistence.

[not-meet]

Added record retention with pruning, and a bounded query window, plus the constants for both.

• Day-keyed records now have retention: each store keeps a small index of which days it has data for and prunes anything past DAY_RECORD_RETENTION_DAYS on write, so they don't grow forever.
• Added a cache so the pruning check only runs once per calendar day instead of on every write.

[not-meet]

hey @scuciatto ! I've added all the suggestions given please take a look !