fix(operator): terminate other client backends before drop_schemas_on

[passcod]

🤖

Summary

Before each `DROP SCHEMA … CASCADE` during schema-migration prep, ask postgres to terminate every other client backend on the target database. The operator owns the restore database fully until handover, so any other session is necessarily a stray or transient client whose lock-holding would queue the DDL indefinitely.

Real failure mode this prevents: an external session got stuck mid-`CREATE TABLE` in the target restore while it was still in the operator's `Switching` phase, holding namespace locks that every subsequent DROP SCHEMA attempt queued behind for 20+ hours. Each operator-restart left another DROP queued, eventually 20+ orphaned sessions. The `DROP`'s patient wait (now correct since we removed the wall-clock timeout) made things worse here because there was no time bound either.

Shape

• New `terminate_other_backends(pg)` helper in `postgres.rs` running:
  ```sql
  SELECT count(*) FILTER (WHERE pg_terminate_backend(pid))
  FROM pg_stat_activity
  WHERE datname = current_database()
  AND backend_type = 'client backend'
  AND pid <> pg_backend_pid()
  ```
• Called at the top of `drop_schemas_on` so every drop run clears the deck first. Returns the count for logging.

Caveats

• Best-effort: backends stuck in uninterruptible kernel waits won't exit on SIGTERM (the case that triggered this eventually needed a pod restart). But those are rare; the 99% case is a normal live client and `pg_terminate_backend` handles it.
• A follow-up structural fix is planned: gating the Service selector on an operator-set `ready-for-traffic` label so external clients can't reach a restore at all while it's still in `Switching`. That eliminates the precondition for this whole scenario.