Scope remote-db keypairs by vault

[cyc60]

Description

Scope remote-db keypairs by vault

KeyPairsCrud filtered the {network}_keypairs table only by network, never by vault, even though the CLI is invoked per vault. When two vaults share one remote Postgres database, one vault's process could read, decrypt, and export another vault's validator private keys, and remote-db cleanup deleted every vault's rows at once.

Every query is now scoped to settings.vault:

• create_table restores the vault column with a UNIQUE (vault, public_key) constraint (previously a global per-column UNIQUE), plus an idempotent ALTER TABLE ... ADD COLUMN IF NOT EXISTS vault so an existing table without the column is upgraded in place rather than crashing on the new queries.
• get_keypairs_count, get_first_keypair, and get_keypairs filter WHERE vault = ..., so key export and the encryption-key check operate only on the current vault's rows.
• remove_keypairs always filters by vault, so cleanup removes only the current vault's keys.
• upload_keypairs inserts the vault column. This also corrects the INSERT, which named three columns but supplied four %s placeholders and three-tuple rows — it raised on any real insert, so remote-db upload-keypairs had been non-functional.

RemoteDatabaseKeyPair is unchanged: the vault is process context, supplied directly in SQL. The previous tests mocked the database connection wholesale, so the SQL was never exercised; the new test_database.py drives KeyPairsCrud with a fake cursor that records the emitted SQL and parameters, asserting vault-scoping on every read/delete and the INSERT column/placeholder arity.