Provider service split migration can drop rows when generated IDs collide #1411

Problem

The SQLite provider service split migration derives new row_id values with a 32-bit hash and inserts copied rows with INSERT OR IGNORE.

Two distinct connection names, ypw3e5cb and al4jix0b, produce the same generated ID when migrated for the same tenant, owner, subject, and target integration:

service_split_k6bggm

SQLite accepts the first row and silently ignores the second, then the migration deletes both source rows and records completion. The same generated-ID helper is used for blobs, integrations, connections, operation storage, tools, and policies.

Reproduction

1. Seed a Google monolith integration with connections named ypw3e5cb and al4jix0b.
2. Run the provider service split migration.
3. Query the migrated Google connections.

Expected: both distinct connections are present.

Actual: only al4jix0b remains. The source rows have already been deleted.

Expected behavior

• Distinct logical rows receive deterministic, collision-resistant IDs.
• Replaying an existing logical row remains an idempotent no-op.
• An unrelated primary-key conflict fails and rolls back the tenant migration.
• A failed migration preserves the source rows for a safe retry.