CI: nightly PostgreSQL lane for the deterministic integration tier

Filed from @rkihm-BC's review of #3703:

> **No CI lane**, as the PR states. Everything here decays the day after merge without one, and
> since most of this PR *is* the harness, a nightly PG lane is what converts it from a measurement
> into a guarantee. Worth filing before merge rather than after.

## Why

#3703 makes the deterministic integration tier runnable against PostgreSQL and fixes what that
exposed. Nothing currently re-runs it. Without a lane, the PG result is a single point-in-time
measurement taken by hand, and every subsequent merge can silently regress it — the failure mode
being that the next person to run it inherits a large, undifferentiated pile of breakage with no
way to attribute any of it.

## What it should do

- Run `MJ_INTEGRATION_TEST=1 RUN_MUTATION_TESTS=1 mj test suite "Integration Tests — Deterministic"`
against a PostgreSQL database built from `migrations` + `migrations-pg` + `mj sync push`.
- **`RUN_MUTATION_TESTS=1` is not optional.** Mutation-class bundles skip silently without it, and a
green run then means materially less than it appears — that flag alone is the difference between
the 49/61 originally reported on #3703 and the honest 58/61.
- Report the bundle-level pass count, and fail the lane on a *decrease* rather than on any failure,
since the tier legitimately ships with known-failing bundles while PG parity is in progress.

## Known-failing bundles at the time of filing (head `302cd42714`)

| Bundle | Cause |
|---|---|
| IT29 — Cache Gauntlet | mutation-class; newly visible |
| IT67 — Content Vectorization | PG `spCreateContentSource` names `ScheduledActionID`, dropped by `V202608061704` — stale regenerated proc |
| IT74 — Task Graph Execution | TX8/TX9; deterministic across three isolated runs, not root-caused |

Whatever baseline the lane starts from should be these three, so a fourth is a real signal.

## Note on scope

The stored-query dialect gap and the PG migration counterparts are release-time conversion work, not
per-PR work — the lane should measure them, not gate a feature PR on them.

Start by reading #3703 and the existing deterministic integration command: `MJ_INTEGRATION_TEST=1 RUN_MUTATION_TESTS=1 mj test suite "Integration Tests — Deterministic"`. Review `migrations`, `migrations-pg`, and the `mj sync push` setup to understand the PostgreSQL database. Done means a nightly lane reports bundle-level counts, uses the three listed known failures as its baseline, and fails only when the count decreases.

Written by the indexing model from the issue text.