Seed credential vended by Vault — retire the RDS master password from the seed flow

PR #42 fixed how the master password travels; this issue removes it from the trip entirely. The seed still authenticates as `vault_root` read from the AWS-managed master secret — a standing, all-powerful credential used by a routine deploy step, in a workshop whose thesis is that workloads get dynamic, scoped credentials. Vault was built for exactly this: a dedicated database secrets role vends a short-lived seed credential (owner-level on the `banking` schema, e.g. `banking_owner`), the script reads it per run, revokes the lease on exit, and the master secret is never fetched by the seed again.

Design notes settled in review:

- The Vault-issued password still travels through the transient Secret + `secretKeyRef` from PR #42 — Vault does not remove the `$$` expansion bug, only the master credential. Pin a `password_policy` on the role so the charset is declared, not inherited.
- Two checks gate the build, against the live DB before any code: (1) `ALTER TABLE … FORCE ROW LEVEL SECURITY` must be possible for a non-superuser owner — ownership sufficiency is load-bearing for the tenant-isolation claim; (2) confirm who owns the existing `banking` tables — `vault_root`-owned tables force an ownership-transfer step.
- Bootstrap correctness: role creation atomic (`EXCEPTION WHEN duplicate_object`), grant `CREATE` on the database and the schema in the same bootstrap; lease revoked in a trap; role TTL longer than the seed run.
- Content sweep: the three Use Case 2 pages print `granted by /vault_root` strings and claim `vault_root` bypasses RLS as a superuser — moving ownership changes those outputs and the prose around them.
- Touches `infrastructure/modules/vault_config/` (new `vault_database_secret_backend_role`), `applications/banking-app/db/seed.sql`, `infrastructure/scripts/seed-banking-db.sh`; landing the Vault role requires a targeted `terraform apply`.

## How to test

- `grep -c 'secretsmanager get-secret-value' infrastructure/scripts/seed-banking-db.sh` — expect `0`; the seed path no longer reads the master secret.
- `bash infrastructure/scripts/seed-banking-db.sh` twice — both runs pass; Vault audit log shows a `database/creds/` issuance and an explicit `sys/leases/revoke` per run.
- After a run, the ephemeral seed role is absent from `pg_roles`.
- Negative test (the one that catches this bug class): deliver a password containing `$$` through the new path and prove the container receives every byte.
- The three Use Case 2 pages (Verify Per-User Data Access, Scope Enforcement, Credential Revocation) run verbatim with expected outputs matching the new grantor strings.