D1: dependent view over a cascade-rebuilt table isn't drop/recreated (Pass 2c gap)

[dmealing]

Follow-up from #241.

Problem

The diff layer's Pass 2c injects a view drop/recreate pair only for column-altering changes (change-column-*, drop-column, rename-column) via VIEW_RECREATE_TRIGGERS (src/diff/index.ts). It does not cover CHECK/foreign-key/field.enum-values rebuilds, and it has no knowledge of the #241 emit-layer FK cascade's referrer expansion.

Consequences on SQLite/D1:

• A view that depends on a table rebuilt by a check/FK/enum-values change (not a column change) may break — SQLite re-parses dependent view definitions when a table is renamed during the recreate-and-copy recipe. This part is pre-existing (independent of D1: auto-migrate referenced-table rebuilds via FK cascade (follow-up to #226) #241).
• D1: auto-migrate referenced-table rebuilds via FK cascade (follow-up to #226) #241 widens the exposure: a table pulled into the cascade purely as an FK referrer (otherwise unchanged) is now dropped+renamed, so a view depending on that referrer can break with no view drop/recreate injected.

Scope

Narrow (a D1 projection/view over an FK-referrer, with a check/FK/enum rebuild upstream), but it means the #241 docs' "applies cleanly against a populated production database" claim has a known exception (now qualified in the docs).

Fix direction

Extend the dependent-view drop/recreate to the full set of tables a migration rebuilds — including check/FK/enum rebuilds and the cascade-affected (referrer) set — not just column-altering changes. This is a diff-layer change and needs its own real-engine gate (view survives a check/FK-triggered rebuild of the base table, and of an FK referrer). Intentionally NOT bundled into the #241 patch to avoid an unproven diff-layer change.

[dmealing]

Fixed on main in 8ccc7c26 (npm-only, migrate-ts; unreleased — will ship in the next npm patch).

A view over a table rebuilt by a CHECK / foreign-key / evolved field.enum @values change — or a table pulled into the D1 FK-cascade as a referrer — was stranded across the recreate-and-copy DROP/RENAME and failed at apply (error in view …: no such table …). Reproduced on real libSQL for both plain SQLite and the D1 cascade.

Fix: the diff drops a dependent view before the rebuild and recreates it after for the full recreate-trigger set on sqlite/d1 (previously only column-altering changes triggered it; Postgres unchanged — FK/CHECK there are ALTER … ADD/DROP CONSTRAINT, no rebuild), and the D1 cascade owns the drop/recreate of every view over an affected table in the correct order with no double-emit. Gated by 4 real-engine scenarios (direct rebuild, cascade referrer, view on the directly-changed parent, no-double-emit) asserting the view survives + re-diff EMPTY.