chore(api): harmonize tenant_id width between registered_clients schema and API

[dcadenas]

Summary

The registered_clients.tenant_id column was INTEGER while every other tenant_id column in the schema is BIGINT. The Rust API surface uses i64 everywhere, so PR #168 worked around the mismatch by casting tenant_id::BIGINT AS tenant_id on every read.

This change widens the column to BIGINT so the schema and the API surface agree. The casts go away and the implicit i64 → i32 narrowing on writes goes away with them.

Closes #171.

What Changed

The column type changes in a forward-only migration. The existing 0008_registered_clients.sql has already been applied in production, so editing it would break checksum tracking — the new migration is idempotent (guarded on information_schema.columns.data_type = 'integer') and safe to re-run.

• New migration 20260429000000_widen_registered_clients_tenant_id.sql ALTERs the column to BIGINT only when its current type is integer.
• core/src/repositories/registered_client.rs drops the four tenant_id::BIGINT AS tenant_id casts (in list, get, create RETURNING, update RETURNING) and the doc comment that explained the prior INTEGER/i64 mismatch.
• New regression test registered_clients_tenant_id_is_bigint queries information_schema.columns and asserts the post-migration type.

Testing

I ran the affected suites against a fresh local Postgres test database, plus clippy and fmt over the whole workspace.

• cargo test -p keycast_api --test registered_clients_admin_test — 16 passed (CRUD round-trip, including tenant_id equality on returned rows).
• cargo test -p keycast_api --test registered_clients_migration_test — 2 passed (existing seed test + new BIGINT type assertion).
• cargo test -p keycast_core — 50 passed.
• cargo clippy --all-targets --all-features — clean.
• cargo fmt --all -- --check — clean.
• Red-green: confirmed the new migration test fails on the pre-migration schema and passes after the migration runs.

I did not run the full e2e suite or test against a Cloud SQL instance — both rely on infra I cannot reach from this worktree.

Risks

The migration is a widening on an in-production table. PostgreSQL rewrites the column in place (small table, fast) and no values can be lost going INTEGER → BIGINT.

• The migration must run before the new binary deploys, otherwise the cast-free SELECTs would try to decode an INT4 column into i64. Both deployment paths preserve this ordering: cloudbuild.yaml runs the migration step before the build/deploy steps, and the binary's --migrate runs migrations before serving.
• Per memory project_migration_pipeline_bug.md, the cloudbuild psql glob database/migrations/00[1-9][0-9]*.sql does NOT match 2026* filenames, so prod actually applies recent migrations through the binary's --migrate (sqlx::migrate) path rather than the cloudbuild psql step. That bug is out of scope for chore(api): harmonize tenant_id width between registered_clients schema and API #171 — surfaced as a follow-up on chore(admin): add durable audit trail for registered_clients admin changes #170 already.

[NotThatKindOfDrLiz]

Reviewed. I agree with the shape of this PR. This is the right fix for the tenant_id width mismatch: a widening migration, removal of the compensating casts, and a regression test that locks the schema expectation in place.

I do not see a blocker here. The rollout and rollback story is straightforward, and the surrounding cloudbuild psql glob bug is useful context but not something this PR needs to solve.

Approving.