Integration framework: rig capability for schema-mutating + DB-tier + browser FLS tests (automate test-plan 2.7/2.8/2.10, 5.1–5.6, Tier 3b)

The Field-Level Security test plan has a set of scenarios that cannot be expressed in the
79-bundle integration catalogue and were verified **manually** on 2026-09-05 (full results:
`plans/fls-redesign-test-plan.md`, "Results — manual live run (2026-09-05)"). This issue tracks
giving the framework the rig capability to automate them.

### Why these don't fit the catalogue (from `plans/fls-integration-test-scoping.md` §2)

1. **No child-process capability in the check contract.** Zero occurrences of
`execSync`/`spawnSync`/`child_process` in `src/checks/` — checks are in-process functions
against a live provider. Every scenario below is "change the schema → run `mj codegen` →
assert", and `codegen-determinism` deliberately verifies existing artifacts *without* running
CodeGen.
2. **Schema mutation is unsafe on the shared dev database.** These tests add/drop columns and
FKs and swap base views between generated/custom/layered. The existing tier's discipline is
read-only-or-self-cleaning against a shared DB.
3. **CodeGen needs its own connection and process.** It runs as `MJ_CodeGen` across ~390
entities; interleaved runs against a shared DB corrupt metadata (`migrations/CLAUDE.md`,
one-database-per-agent).

Plus two capabilities beyond CodeGen: **`sa`-level logins** (5.4/5.5 need `CREATE LOGIN`, role
membership, and a direct SQL connection that must *fail*), and **a browser** (Tier 3b is nine
Angular cases; the framework is explicitly headless).

### The durable deliverable: a disposable-database helper (scoping §3)

Create per-run database (`mj_fls_it_`) → migrate → codegen → run → drop. The pieces
exist: `sa` is available in the `sql2022` container, and the `bootstrap-clean-db` skill is the
manual version of exactly this setup (verified again in this run: 71 migrations + codegen +
sync push, all clean, ~4 minutes end to end). This helper is a framework investment, not an FLS
one — the layered-base-view and metadata-sync bundles would use it too.

### Scenarios to automate

| Group | Scenarios | Manual baseline (2026-09-05) |
|---|---|---|
| CodeGen reconciliation | 2.7a–2.7d (column/FK/computed/layered-view additions), 2.8a–2.8d (removals), 2.10 (idempotency) | 2.7a/c/d, 2.8d, 2.10 ✅ · 2.7b ✅ but needs TWO codegen runs (FK display column's `EntityField` is created after reconciliation in the same pass; fail-closed in between) · 2.8a/b/c mechanism ✅ via direct `spDeleteUnneededEntityFields` call; end-to-end 🔴 blocked by the two CodeGen bugs below |
| DB tier | 5.1–5.5 (DENY emission, No-Access neutrality, flag-off revoke, service-login backstop, direct-SQL denial) | all ✅ |
| Propagation | 5.6 multi-session (two MJAPI processes) | ✅ 25.6s with a 15s refresh interval on the observing server |
| Angular | Tier 3b, nine cases (Playwright + a real IdP-backed account holding an FLS-denied role) | ⏸ never verified live — unit-covered only, with stubbed users/metadata |

**2.8a matters most**: it is the only regression check for the shipped
`spDeleteUnneededEntityFields` + `ON DELETE CASCADE` fix (`ef953d2876`), which today has
manual-only coverage.

### Two general CodeGen bugs found during the manual run (may deserve their own issues)

1. **Dropping columns from an entity with a generated base view leaves CodeGen in a broken state that re-running does not repair.**
Pass-1 metadata sync runs while the old view's catalog still lists the dropped columns (so the
stale `EntityField` rows aren't orphaned); view regeneration then emits SQL referencing the
dropped column from that stale metadata and fails; the view is left dropped; and subsequent
runs never re-attempt field deletion because the Pass-2 `manageEntityFields` call is scoped to
new/modified entities. Three consecutive failed runs observed; recovery required a direct
scoped `EXEC __mj.spDeleteUnneededEntityFields` (which succeeded cleanly — the cascade fix
works; the orchestration just never reaches it).
Repro: `ALTER TABLE flstest.Gadget DROP COLUMN ` (+ drop the auto FK index first if the
column is an FK) on an entity with a generated `SELECT s.*` view → `mj codegen` twice.
2. **Narrowing a custom base view collides on `UQ_EntityField_EntityID_Sequence`.** Reproduced in
isolation: `ALTER VIEW` to stop selecting a mid-sequence column (still on the table) →
`manageMetadata` aborts with a duplicate-key insert at that column's old sequence during
"updating existing entity fields from schema" — and the abort takes the whole metadata phase
down for every entity in the run.

Side observation, separate subsystem: a user API key minted through MJAPI process A was not
honored by sibling process B for >2 minutes despite `scopeCacheTTLMs` defaulting to 60s.

### References

- Manual results + pass conditions: `plans/fls-redesign-test-plan.md` (2026-09-05 section)
- Scoping research: `plans/fls-integration-test-scoping.md` §2–§4 (phases 3–5 are this issue)
- Platform metadata-refresh fix underpinning 5.6: PR #4249
- FLS feature PR: _(link once it exists)_

Start with plans/fls-integration-test-scoping.md §2–§4 and the manual results in plans/fls-redesign-test-plan.md, then review the bootstrap-clean-db skill as the existing setup baseline. The work is done when the framework can create, migrate, codegen, run against, and drop a disposable database while covering the listed CodeGen, DB-tier, propagation, and browser scenarios.

Written by the indexing model from the issue text.