chore(keys): remove the initKeys and keyManager scaffolding, which writes keys nothing reads

[Bccorb]

Fell out of #205, where initKeys was removed from the container entrypoint (#236). The step is gone from the boot path, but the code is still in the tree and still wired into the dev stack, and it does nothing useful in either mode.

What it does

src/scripts/initKeys.ts calls ensureKeys() in src/scripts/keyManager.ts:

• Production: ensureKeys() is if (!isProduction) { ... } followed by a comment placeholder. It returns immediately. Real keys come from SEAMLESS_JWKS_KEY_*_PRIVATE, which validateEnvs.sh requires.
• Development: it writes ./keys/private.pem and ./keys/public.pem. Nothing reads either file. src/utils/signingKeyStore.ts keeps its own dev keys at ./keys/dev/ and generates them lazily with an exclusive write, and src/controllers/jwks.ts serves ./keys/dev/public.pem. Two different directories.

So a fresh dev clone generates two RSA keypairs, and one of them is never used.

What is left to clean up

• docker-compose.dev.yml still runs npx tsx src/scripts/initKeys.ts in its command chain. Left in place in perf(boot): drop two dead Node processes from container start #236 to keep that PR to the production boot path and avoid colliding with fix(dev): read RPID from the environment in the dev stack #237, which also edits that file.
• Dockerfile still does RUN mkdir -p ./keys. Harmless, and signingKeyStore creates ./keys/dev itself, but worth confirming before removing since the directory is chowned to appuser.
• src/scripts/initKeys.ts, src/scripts/keyManager.ts, and their two specs.

The judgement call

keyManager.ts is not obviously abandoned. Its production branch carries a deliberate placeholder:

// PRODUCTION MODE
// Implement a first time JWKS rotation. See Seamless Auth docs for guides

So this is either scaffolding for first-boot JWKS rotation that should be built, or a stub that should go. That is a product decision, not a cleanup one, which is why #236 removed the boot cost and left the files alone rather than deleting JWKS-adjacent code in a performance PR.

Decide which, then either:

• build it, and make the dev path use one key directory rather than two, or
• remove it, dropping the compose line, the two source files and their specs, and folding anything worth keeping into signingKeyStore.

Either way the dev stack should stop generating a keypair nothing loads.

[Bccorb]

Cross-link: this overlaps #175 (Production JWKS key rotation is not implemented, P2/govramp).

The placeholder that makes this a decision rather than a cleanup is exactly that feature:

// PRODUCTION MODE
// Implement a first time JWKS rotation. See Seamless Auth docs for guides

So the two are the same fork seen from different ends. #175 asks for production key rotation; this asks whether the empty function reserved for it should be built or deleted. Whichever way #175 goes decides this:

• Production JWKS key rotation is not implemented #175 gets built here: keyManager becomes real and the dev path should stop writing to a second, unread directory.
• Production JWKS key rotation is not implemented #175 gets built elsewhere, or rotation is handled operationally outside the process: nothing is reserving keyManager, and it plus initKeys, their two specs, and the docker-compose.dev.yml line should go.

Worth deciding #175 first and letting this follow, rather than resolving them independently and finding the answers disagree.