fix(cost): retain daily rollups for 180 days

[AsperforMias]

Summary

• Retain daily usage rollups for 180 days, covering both current and previous 90-day comparison windows.
• Extract the production retention cutoff and predicate so the retention boundary is directly testable.
• Fixes fix(cost): retain daily usage rollups for both 90-day comparison windows #286.

Why

The prior cleanup used a 90-day window relative to an already seven-day-old detail cutoff, retaining roughly 97 days. That deletes data required by the cost dashboard previous-period comparison and can make historical totals incomplete.

Verification

• Commands: just test-file apps/api/tests/cost-rollup.test.ts (1 passing); just check (939 passing tests, plus format, docs, lint, type, and GraphQL checks).
• Manual steps: Used deterministic UTC time with the local SQLite D1 fixture. Applied the exact production retention predicate, verified a date within the 180-day horizon remains, verified an older date is removed, and queried the real LAST_90_DAYS comparison path.
• Not run: A remote D1 retention-job execution. No Cloudflare account resources were available for an isolated remote deployment, so no remote resources were created and no account usage or billing was incurred. The deterministic local regression verifies the retention and read-query boundary; this is not a claim that a remote Cloudflare incident was observed.

Impact

• User/API/contract changes: No public API changes; historical cost comparison data is retained according to the product requirement.
• Generated files / GraphQL / DB / lockfile: N/A.
• Env or config changes: N/A.
• Risk and rollback: Daily rollups consume up to roughly twice the prior retention storage. Revert this commit to restore the previous retention cutoff, with the associated loss of previous-window history.

Review

• Closest review areas: Cost rollup service, cost query service, daily-rollup retention policy.
• Known trade-offs: The additional 83 days of retained aggregate rows increase D1 storage modestly; aggregate rows are small and required for the documented 90-day comparison.

[github-actions]

All contributors on this pull request have signed the CLA.
_{Posted by the CLA Assistant Lite bot.}

[AsperforMias]

I have read the CLA Document and I hereby sign the CLA

[Yevanchen]

Verified against the actual query semantics: getOrganizationBillingCostCard computes the previous LAST_90_DAYS window as resolveCostWindow(range, new Date(window.sinceMs - 1)), whose oldest needed rollup date is today-179, while the old cleanup predicate retained only ~97 days -- so previousTotals was silently truncated once the system ran long enough. The 180-day cutoff covers the previous window with a one-day margin, and the pre-streamline PRD explicitly documented the 180-day retention contract. The test pins the exact boundary (cutoff 2026-01-14, boundary row 2026-01-15 retained) through the real production predicate and real queryTotals path. LGTM.