[dmealing]

What changed

Three separate faults when a column is dropped from under a view. None depends on @column, which is unchanged, as is the rename guard that refuses a drop-and-add in the same table.

• Plan-time block. With --from-db, meta migrate now refuses a drop-column that a live view it does not own still reads: a declared @unmanaged view, a hand-made view not in the metadata, or one outside the scoped schemas. The message names the view and the column. Before, the migration was written and failed at apply (Postgres: cannot drop column ... because other objects depend on it; SQLite: error in view ... after drop column). A view with no recorded body is not matched, and offline mode cannot see live views, so it is unchanged.
• New allow flag: --allow drop-column-read-by-view (allow.dropColumnReadByView, also a config token). Why it exists: the check is a text match on the table and column names, so it can over-report; an operator who has dealt with the view, or knows the match is a false positive, needs a deliberate way past. It follows the existing blockedBy and allow-flag pattern used for drop-view-cascade.
• SQLite and D1 down migration for drop-column now re-adds the column instead of writing a TODO comment, so a rolled-back view works again. Data is not restored, and the migration says so. A NOT NULL column with no default comes back nullable, and a non-constant default is omitted, because SQLite refuses to add such a column to a populated table; each case carries a NOTE line.
• Docs. docs/features/migrations-and-drift.md and the authoring skill's views reference now say to edit an @sql body in the same change that removes a column it reads: the tool never parses it, so Postgres fails at apply and SQLite applies and leaves a broken view. Agent-context fixtures are regenerated. CHANGELOG.md [Unreleased] records all three.

Testing

• New unit tests (migrate-ts) for both dialects: an unowned view that reads the column is blocked and named, one that does not is not, a body-less view is not, the flag lifts the block, and the SQLite and D1 downs.
• New integration tests on real SQLite and real Postgres: the block, the apply-time failure it prevents, and a SQLite rollback that queries the restored view.
• The migrate-ts, codegen-ts, cli and sdk suites pass with 0 failures.
• The pipeline drove the SQLite CLI live in --from-db mode (disposable project): a hand-made view and an @unmanaged view each read the dropped column and the plan is blocked; apply then rollback re-adds the column and the view is queryable.

Gate

The no-mistakes gate took 1 run. Review raised the SQLite non-constant-default case (fixed) and asked whether the new allow flag is wanted (kept, per the reason above). Test found that the block did not count a hand-made in-scope view as unowned and fixed it.

The Test step was approved with an exception, not a clean pass: the configured scripts/ci-local.sh --only ts-fast --only ts-unit wrapper did not finish inside the pipeline's time budget, so its result was not confirmed there, and the live run did not cover Postgres. Hosted checks run the full suite before merge.