v0.23.0

Bundled sqlift bumped to v0.14.0

Two new opt-in flags surface in sqlift_apply_options.allow:

#define SQLIFT_ALLOW_LOOSEN         (1u << 2)
#define SQLIFT_ALLOW_DATA_DEPENDENT (1u << 3)

SQLIFT_ALLOW_LOOSEN permits rebuilds whose only changes are strict
relaxations of existing constraints (drop a CHECK or FK, NOT NULL becomes
nullable). Independent of SQLIFT_ALLOW_REBUILD: a pure-loosening rebuild
passes either gate. Lets callers express a backwards-compatible-only
policy.

SQLIFT_ALLOW_DATA_DEPENDENT permits changes whose success depends on
existing data (nullable→NOT NULL, new FK or CHECK on an existing table,
new NOT NULL column without DEFAULT). Combine with SQLIFT_ALLOW_REBUILD.

SQLIFT_ALLOW_ALL now includes both new bits.

Behavior change

BreakingChangeError moves from a diff-time throw to an apply-time
policy gate. sqlift_diff now produces a plan whose RebuildTable ops
carry data_dependent: true; sqlift_apply rejects them unless
SQLIFT_ALLOW_DATA_DEPENDENT is set. The error type is unchanged.

For sqlpipe consumers, both internal sqlift_apply call sites still
produce errors for problematic data-dependent changes — only the call
site of the error differs:

• auto_migrate (uses SQLIFT_ALLOW_ALL): now accepts data-dependent
  migrations on clean data. Previously sqlift_diff would have thrown,
  causing auto-migrate to fail. Now the migration succeeds when data
  conforms to the new constraints, and fails with SQLIFT_APPLY_ERROR
  when it doesn't. Net: more permissive in the clean case, equivalent
  in the dirty case.
• Database ctor with schema_ddl (uses SQLIFT_ALLOW_REBUILD only):
  data-dependent changes now produce SQLIFT_BREAKING_CHANGE_ERROR at
  apply time, where they previously produced an error at diff time.
  Same outcome wrapped the same way.

Tests

• C++: 154/154 tests pass (sqlpipe's own + bundled sqlift's behaviors)
• Go: all subtests pass