secret store holds foreign secrets, and notify reads from it

putSecret/getSecret, `bun run secret:set`, and notify taking its credentials
from the store with env as the fallback. this was described two messages ago
as a later thing; it is about fifteen lines and it was blocking the honest
answer to "where does the .p8 go", so it is done.

getKey was the wrong door for anything supplied from outside — it MINTS a
random 32-byte value when the purpose is absent, which for a foreign
credential means silently authenticating to apple with a fake. getSecret
returns null instead, which is what lets the env fallback work.

putSecret retires the previous row rather than deleting it: a mistyped paste
over a working key should be recoverable, and retiredKeys already exists for
that shape. one transaction, because the partial unique index means the retire
has to land before the insert.

the CLI reads stdin and has deliberately no --value flag: a secret in argv is
in shell history, in ps output, and in any audit log that records command
lines. offering the flag would make the convenient path the leaky one. it
prints a length and the last four characters, never the value.

also `bun run notify:test`, which fires officer/core:test at a registered
device. the sidecar's port is ephemeral, so it now writes its address to
data/notify-server.url on boot and removes it on clean shutdown; the CLI
treats an unreachable address as "not running" rather than trusting the file,
because a crash leaves one behind.

the script says what actually happened, because the day-waster here is that a
send with nothing configured returns success and delivers nothing — it refuses
up front when channels is empty, and calls out sent:0/failed:0 as "no device
registered" rather than letting it read as success.

verified end to end with a p-256 key generated locally and then deleted from
the store: zero APNS vars in .env, sidecar reported channels: apns, and the
send reached the channel. store is back to jwt and offscale only.

TODO.md

@@ -698,19 +698,12 @@ outside the example's new README:
       unreachable from the LAN while localhost and Tailscale work.
       Fix: `sudo ufw allow from 192.168.47.0/24 to any port 9010 proto tcp`
 
-- [ ] **Move the APNs `.p8` into the secret store — and teach the store to hold a foreign secret.**
-      Agreed 2026-08-19 when the key went into `.env` as an interim. The store's own argument applies
-      almost verbatim: `.env` is auto-loaded by bun into every PM2 process, so a credential there is
-      readable from `/proc/<pid>/environ` of twenty processes — `officer-music` and `officer-pty`
-      would both be able to read a key that can push to your apps forever and does not expire.
-
-      **The blocker is not a purpose string.** `getKey(purpose)` GENERATES a key and returns it; there
-      is no setter, because everything in the store so far is a key the platform minted itself. The
-      `.p8`, the APNs Key ID, the Team ID and the FCM service-account JSON are all supplied from
-      outside, so this needs a `putSecret(purpose, value)` and a decision about who may call it.
-
-      Same applies to `DISCORD_WEBHOOK_URL` and every plugin credential still read from env.
-      See `docs/secret-store.md` and `docs/push-notifications.md`.
+- [ ] **Move the remaining env credentials into the secret store.** `putSecret`/`getSecret` and
+      `bun run secret:set` landed 2026-08-19, and notify now reads `apns-p8`, `apns-key-id`,
+      `apns-team-id`, `fcm-service-account` and `discord-webhook` from the store with env as a
+      fallback. Every other plugin credential is still env-only — same argument applies: bun
+      auto-loads `.env` into every PM2 process, so each one is readable from `/proc/<pid>/environ`
+      of twenty processes that have no business with it.
 
 ## Backburner