Collect per-template deployment counts

[ak40u]

Problem

workspaceTemplates reports health as a rounded percentage. A percentage alone does not say how much activity it covers: a template sitting at 88% could have had two failed deploys or twenty, and nothing stored says which.

Change

Collect templateMetrics alongside the existing queries. It carries the counters behind the percentage — totalDeployments, deploymentsLast90Days, activeDeployments — plus supportHealth and per-template earnings.

• New table template_deployment_snapshots. Deploy counts are a different population from the project counts already stored — they include redeploys of an existing install — so they get their own table instead of columns on template_snapshots, and no existing view or dashboard changes.
• New view template_deployment_activity differences consecutive snapshots into deployments_added, and reports health_change beside it.
• ensureSchema now drives off a REQUIRED_TABLES list rather than a hardcoded 3, so the schema file re-runs once on existing databases to add the new table. Every statement in it is idempotent.

Two traps, both hit in practice

I originally stored a failed_deployments column computed as total_deployments * (100 - health) / 100, and a failures_added delta on top of it. Both are wrong, and the first two days of real data showed it:

1. The counter and the percentage cover different periods. Deploys are counted for the lifetime of the template; health is a percentage over a rolling window whose size is not published. When the window empties, the formula reports zero failures for deploys that did fail. One of my templates went from "6 failed" to "0 failed" without a single deploy in between — a change of minus six failures in a day.

2. templateMetrics returns templateHealth: 100 when it has nothing to report, which is indistinguishable from a genuine 100%. The public health field is null in that same case. That is what the health_reported column is derived from, and the view returns NULL health rather than a default presented as a measurement.

So this PR deliberately reports no failure count. What it does report is what holds up: deployments_added (the counter is monotonic, so the difference is real) and health_change next to it. A health drop against a positive deployments_added is the signal worth chasing.

Batching

templateMetrics takes one template id per call, so the query is built with an alias per template. Sending all of them at once fails:

Query exceeds maximum Breadth (Breadth: 570, max: 500)

Each template costs ten nodes (its own plus nine fields), so requests go out in batches of 40 — under the cap with room for a field to be added later.

Verification

Run against a workspace of 57 templates across two daily collections: two batched requests per run, 189 deploys tracked, rows written and the view returning as expected. Deltas are NULL on the first snapshot, which is correct — there is no prior row to compare against.

Unit tests cover the query builder (alias/variable agreement, selected fields, batch size against the breadth cap). The database tests need a live Postgres and were not run in this environment.