Fix/move table schema migrations

[febarnett3]

Contributor checklist

Leave anything that you believe does not apply unchecked.

• I accept the AI Policy, or AI was not used in the creation of this PR.
• Bug fixes include regression tests
• Chores
• Documentation changes
• Features include unit/acceptance tests
• Refactoring
• Update dependencies

Summary

Resolves issue #731
Fixes schema-only resource changes being generated as drop table + create table.

The generator matches snapshots by {table, schema}, so changing only schema "..." made the old table look removed and the new schema table look newly added. This PR detects same-table/different-schema changes as schema moves and emits ALTER TABLE ... SET SCHEMA ... instead, preserving existing data.

Changes

• Added MoveTableSchema operation.
• Reconnects old/new snapshots when a table moves schemas.
• Prevents orphaned old-schema snapshots from becoming table drops.
• Ensures schema moves run before later changes against the new schema.
• Avoids unnecessary FK drop/recreate when a referenced table moved schemas.
• Tests

Added test coverage for:

• Adding a schema to an existing table.
• Moving from one schema to another.
• Moving schema and adding a column in the same migration.
• Moving a referenced table without recreating FKs.

[zachdaniel]

I think we may need to ask if you are renaming the schema or not interactively, similar to how we do with other renames. The reason for this is that I think there could be some weirdness here if you have the same table but in different schemas. We may want some tests around those scenarios as well.

[febarnett3]

That's a good point. I agree this should probably mirror the table rename behavior. The current logic assumes one same-table/different-schema candidate means a schema move, but that could be ambiguous if an unrelated table with the same name is added in another schema. I can add an interactive confirmation and tests around that case.

[febarnett3]

Added the suggested prompt handling for inferred schema moves. If the user declines the schema move, the generator treats the target-schema table as new and falls back to the existing orphan-table drop prompt for the old table, allowing the same table name to intentionally exist in different schemas.
I also guarded the deduped snapshot matching path so a declined schema move cannot still generate ALTER TABLE ... SET SCHEMA, and added regression tests for the decline behavior.