Treat loosening a Point or polygon field contract as a compatible change #2646

Changing a crs84-point or crs84-polygon field's contract is always treated as a destructive field type change, even when the change only loosens it. Raising maximumPositions (say from 100 to 500), raising precision, or widening or removing bbox cannot invalidate any retained value, yet the author has to write a reviewed migration with at least one SQL step, bind a backup and run a rehearsal.

Where

• package.rs reports any geometry contract change as FieldTypeChanged.
• FieldTypeChanged is not metadata-only (covers_are_metadata_only in migration_plan.rs), so a migration descriptor with no steps is refused.
• The widening rules in contract.rs cover other field kinds but not Point or polygon contracts.
• The polygon migration test needs a no-op rewrite step to change a contract (tests/postgres_spatial_migration.rs).

Point precision changes already behave this way, so #2644 is consistent with existing behaviour; this issue covers both.

Proposal

Classify loosening of a Point or polygon contract (higher maximumPositions, higher precision, wider or removed bbox) as a compatible change: the compiler regenerates the CHECK constraint and the generated PostGIS projection, with no SQL step, backup or rehearsal required. Tightening keeps the reviewed migration path, which already refuses retained values that violate the candidate contract before activation.

Until then, products/breg/SPATIAL-QUERIES.md should say what a contract change costs.