destructive-op guard: prevent_destroy/protect for tables, MVs, dictionaries

Symptom

Removing an object from HCL emits a runnable DROP TABLE with no guard. Only in-place-impossible changes are withheld from the SQL stream (internal/loader/hcl/sqlgen.go:168-174); intentional-looking drops are emitted as executable DDL. There is no Terraform-style prevent_destroy/protect mechanism.

Impact

An accidental deletion of a table block (bad merge, wrong layer resolution) generates a DROP that, once an apply path exists or an operator pipes the output, destroys data with no friction.

Fix direction

• A protect = true (or lifecycle { prevent_destroy = true }) attribute on tables/MVs/dictionaries that turns a generated DROP into an error.
• Optionally a global -forbid-drops flag for CI diff runs.

Found in the 2026-07-02 deep-dive audit (docs/plans/2026-07-02-deep-dive-improvement-areas.md, C2).

Start at internal/loader/hcl/sqlgen.go:168-174 and read the C2 entry in docs/plans/2026-07-02-deep-dive-improvement-areas.md. Trace how table, materialized view, and dictionary removals become DROP statements, then clarify whether the project should use protect, lifecycle prevent_destroy, the global -forbid-drops flag, or a combination. Done means the chosen guard prevents unintentional destructive output as an error.