Secrets management: migrate ansible-vault credentials to a real secret manager (AWS Secrets Manager or 1Password)

## Problem
Credentials for unglue.it live in several places with no single owner: `group_vars/*/vault.yml` (ansible-vault: app DB user, SES, Stripe, OAuth… — one shared vault password), static IAM keys in `prod.wsgi` (#59), and things nobody wrote down at all (the RDS root password — https://github.com/EbookFoundation/regluit-provisioning/issues/75). Rotation is manual and undocumented; reading a value safely requires decrypting a whole file.

## Proposal (discuss with Eric before choosing)
Pick one bona fide secret manager and migrate incrementally:
- **AWS Secrets Manager** — native to where the servers already are; Ansible can pull via `amazon.aws.aws_secret` lookup with an instance role (pairs with #59); RDS can *manage* the master password itself (`ManageMasterUserPassword`) and rotate it.
- **1Password** — where the humans already are; `op` CLI / Connect server for Ansible; service accounts for CI.
Either way: one credential per item, per-environment, with an owner and a rotation date; ansible-vault becomes a thin shim or goes away.

## First steps
1. Inventory every secret in the vaults and `prod.wsgi` (names only, no values) — where used, who rotates.
2. Decide the store (Thu 9/17 agenda).
3. Migrate the RDS root password first as the pilot (new, so no legacy readers).

Start by inventorying secret names and usage in group_vars/*/vault.yml and prod.wsgi, and read issue #75 for the RDS root-password context. The work is done when a secret manager is chosen, ownership and rotation are recorded, and the RDS root password has been migrated as the pilot without exposing values.

Written by the indexing model from the issue text.