sql: don't drop table constraints after a nullable UNIQUE - #39598

Contrary to the commit message, keys are part of the persist schema. SourceData::encode_schema stores ProtoRelationDesc, which includes ProtoRelationType.keys. Persist looks up a writer's schema by full RelationDesc equality (src/persist-client/src/internal/apply.rs:262, src/persist-client/src/internal/state.rs:1622). On a mismatch it returns None once a schema already exists. Only MVs get a bootstrap schema evolution (evolve_nullability_for_bootstrap). Tables and source exports have none.

I reproduced both paths by stopping the parent commit's image (134006ec86) and starting this commit's image on the same /mzdata:

• Table: CREATE TABLE t (a int, b int, UNIQUE (a), PRIMARY KEY (b)) is accepted without unsafe mode before this change, because keys stays empty and the unsafe_enable_table_keys gate is skipped. INSERT INTO t VALUES (1, NULL) also succeeds. The new image re-plans t as b NOT NULL, keys [[1]], because unsafe_enable_table_keys is enable_for_item_parsing. environmentd then aborts in register_table_collections at src/txn-wal/src/txns.rs:229 ("schema should be registered"), exit 134, on every restart. Even without the panic, the shard holds NULLs in a column now typed NOT NULL.
• Postgres source: upstream s (a int, b int NOT NULL, UNIQUE (a), UNIQUE (b)) with CREATE TABLE s FROM SOURCE. Only the keys change ([] to [[1]]). clusterd panics in persist_sink::append_batches at src/persist-client/src/write.rs:745 ("fetching a schema id should only fail when the shard is tombstoned") about every 6s. That takes down the whole replica. The same applies to a PK plus a nullable UNIQUE plus a NOT NULL UNIQUE, a common upstream shape, and to MySQL.

From reading the code, 0dt does not catch this either. In read-only mode only migrated builtin tables are registered (src/storage-controller/src/lib.rs:1516) and sources do not append, so the failure appears only after promotion.

Suggested fix: keep the desc of existing items stable. Add a catalog migration that removes the UNIQUE/PRIMARY KEY table constraints the old planner never applied from stored create_sql, meaning every Unique constraint from the first nullable, non-NULLS NOT DISTINCT one onward. A per-export details flag, like cast_oid_full_range, would also work. Only newly created objects should get the fixed semantics. An upgrade check (platform-checks) with this table shape and this Postgres shape would cover it.