Org-level monthly time-series storage (productionize org monthly data)

[peetzweg]

Part of #106 — give organizations the same monthly time-series users already have, so org charts and org trends (sub-issue D) are possible.

Problem

On main, orgs store only lifetime totals (entities + org_members) — no monthly resolution. So there's no org commit chart and no way to compute an org's month-over-month change. Users already have monthly_commits (all six types per completed month); orgs have nothing equivalent.

What exists to build on

The unmerged #102 / feature-async-org-indexing branch already prototypes this: an org_member_monthly table (per org/member/month), rolled up into org-level monthly_commits rows, plus the org commit chart in OrgView. This issue is about productionizing that — landing the migration, the worker fill path, and the rollup — on top of the cadence (A) and runner (B) decisions.

Acceptance criteria

• Per-month org contribution storage lands (migration for org_member_monthly or equivalent) — the DB change we've deliberately deferred
• Worker fills org monthly data politely (paced, idempotent, resumable), rolled up into org-level monthly_commits
• Org page renders the commit chart from stored monthly rows
• Plays nicely with Keep historical org memberships — departed members silently shrink company totals #97 (departed members must not silently shrink historical months)

Depends on

Cadence (A) + runner (B). Enables D (org MoM indicator). Supersedes the org half of #102.

[peetzweg]

PR #102 was closed unmerged on 2026-07-29 (housekeeping — not a change of plan). The prototype this issue builds on is still on feature-async-org-indexing at 8b09342: the org_member_monthly table, the rollup into org-level monthly_commits, and the OrgView chart. Worth keeping that branch alive until this lands, since the "What exists to build on" section points at it.

Meanwhile the user-side equivalent shipped in #145 (closing #144), and its shape is directly reusable here rather than reinvented:

• a pure engine (src/lib/monthly-user-refresh.ts) behind a store interface, so the scheduling/pacing logic is unit-testable without a DB
• a bundled worker entrypoint at .output/worker/, run as a Coolify scheduled task on the app image (no separate service)
• a Postgres advisory lock on a reserved connection, so overlapping scheduled passes exit cleanly
• a reserved GraphQL points floor with reset-aware waiting, so a batch job cannot drain the token the live site shares
• skip-if-already-present, which makes every pass idempotent and turns the missing rows into the retry queue

The org worker wants its own advisory lock and a stricter default limit (~25 orgs), per the follow-up section in #144.