ci: reserve the docker+postgres runtime tier for postgres-relevant changes — the saving #1158 set out to get

[rickylabs]

Summary

PR #1220 (issue #1158) landed a working container-reduced runtime tier, scaffold.runtime.sqlite, and wired it into CI. But measured on a clean GitHub runner it does not yet deliver the compute saving #1158 set out to get, because the postgres tier still runs on the same signal.

Evidence

From run 30941839021, both jobs green, both genuinely executed:

Job	E2E step	Total
scaffold-runtime-sqlite	4m 12s	4m 55s
scaffold-runtime (postgres)	4m 24s	4m 59s

12 seconds apart (4.5%). Dropping postgres and redis containers is nearly free on cloud infrastructure — cached images, container startup is not the bottleneck. The heavy cost is a local WSL phenomenon, where the tier is genuinely valuable.

Both tiers currently fire on the same signal for every non-docs change:

cli source      static=true sqlite=true postgres=true
e2e only        static=true sqlite=true postgres=true
plugin source   static=true sqlite=true postgres=true
docs only       static=false sqlite=false postgres=false

So today the sqlite tier adds a parallel ~5-minute job on cloud rather than replacing anything.

The actual saving

#1158's title is "so docker+postgres is reserved for postgres-specific verification". The reservation is the part that saves compute, and it was deliberately left out of #1220:

• ci: scope every expensive job to a capability vector — paths decide, labels override #1152 set the docker signal "deliberately wide in v1 — tightened only against observed green history".
• test(e2e): sqlite-backed runtime tier so docker+postgres is reserved for postgres verification #1220's plan put it in Non-Scope (D6: no merge-readiness flip).

Narrowing it before the sqlite tier had any green history would have been exactly the premature tightening #1152 warned against. It now has its first green run.

Proposal (needs design)

• Narrow run_runtime so scaffold-runtime fires on genuinely docker/postgres-relevant paths (Aspire resource registration, DB provider/adapter code, connection lifecycle, deno.lock provider bumps) rather than on any scaffold-impacting change.
• Keep run_runtime_sqlite on the broad run_static signal, so most PRs still get a full runtime path — just the cheap one.
• Preserve the frozen ci:* label set and the fail-closed classifier behaviour (ci:full forces everything; ci:skip-e2e skips both tiers).
• Keep scaffold.runtime as the merge-readiness bar and as a required check on release branches regardless of path signal.

Acceptance

• A PR touching only e2e/scaffold code runs scaffold-runtime-sqlite but not scaffold-runtime.
• A PR touching DB provider / Aspire infrastructure code still runs both.
• ci:full and ci:skip-e2e semantics unchanged; no new labels.
• Classifier matrix tests cover the narrowed signal, including the fail-closed paths.
• Measured before/after CI minutes recorded on the PR.

Prerequisite

Some observed green history for scaffold-runtime-sqlite — its first green run is 30941839021.

Refs #1158, #1152, PR #1220.