feat(reports): pre-generate canned reports in the bactopia airflow workflow and serve from storage

[thecaffiend]

Summary

Generate canned reports as part of the Airflow workflow that runs Bactopia, store the rendered artifacts, and have the report URL simply fetch a pre-generated artifact from storage instead of rendering on demand.

Motivation

Today the report endpoint (GET /report/create, assets/api/capi/handlers/get_canned_report.py) renders synchronously per request: it invokes the data function (which runs several serial Athena queries), renders the template, and for PDF also runs WeasyPrint. This has two problems:

• The API Gateway REST integration hard cap is 29s. The data function's Athena queries alone already push the HTML path to roughly 25s, so PDF rendering piled on top reliably exceeds 29s and clients get a 504, even though the Lambda timeout is 60s.
• The report Lambda is under-resourced (128 MB), which throttles CPU and leaves little headroom for WeasyPrint.

Moving generation into the pipeline removes request-time latency entirely and makes PDF viable, since rendering happens in the workflow with no API Gateway timeout. The handler's own TODO already anticipates an async generate-store-notify model.

Proposed approach

• Add a report-generation step to the Bactopia Airflow workflow that runs after the sample's analysis outputs are available (Bactopia results, and any downstream result tables the report depends on).
• Render the report (HTML and PDF) in that step and write the artifacts to durable storage (for example an S3 prefix keyed by report id and sample id).
• Change the report endpoint to look up and stream the pre-generated artifact from storage, returning a clear status when it is not yet available, rather than rendering on demand.
• Keep the existing data-function and template assets as the rendering implementation shared by the workflow step; avoid duplicating the render logic.

Open questions

• Storage layout and lifecycle (bucket, prefix scheme, retention) for generated reports.
• Regeneration and staleness: when inputs change or a report is re-run, how artifacts are versioned or overwritten.
• Whether the endpoint should support on-demand fallback for reports not yet generated, or strictly serve pre-generated artifacts.
• Access control on the stored artifacts consistent with the current API authorizer.

Notes

This is a stretch item for the current feature set; attack it after the primary integration lands if time allows. It also supersedes the synchronous-render timeout concerns rather than working around them.