Bound production report workload, query size, and concurrency

[mforce]

Parent: #244
Epic: #15
Severity: Medium
Execution mode: AFK

What to build

Make every production report path bounded under authenticated but hostile use. Current report generation can load all matching history and perform repeated in-memory scans, so one authorized user can drive database, memory, and CPU cost upward as farm history grows.

Push filtering and aggregation into SQL, require bounded date ranges or bounded pagination where a full-history result is not essential, and apply a small report-specific concurrency or rate limit keyed by account. Keep exports separate where their product contract genuinely requires a larger data set.

Acceptance criteria

• Every report endpoint has an explicit, validated maximum date span and bounded result shape, or a documented exception with equivalent pagination/streaming.
• Report handlers do not materialize an account lifetime of raw rows merely to aggregate them in memory.
• Repeated category/period scans are replaced with one bounded query or a bounded number of database-side aggregates.
• Concurrent expensive reports for one account are capped and excess work returns a documented retryable status.
• Limits are tenant-scoped and do not let one farm learn another farms activity.
• Integration tests cover maximum allowed range, one-day-over-limit, cancellation, and concurrency rejection.
• A Release rehearsal: day-in-the-life simulation of 10 users (all roles) with container-resource + HTTP-traffic monitoring #243/SPA UI verification track: Playwright E2E smoke + canary-under-load over the #243 sim fixture #277 production-shaped run records query count, peak memory, and latency at the maximum supported range.

Blocked by

None.