Relay posts its own events, starting with its own app registry #62

Pushed. Tests are green (106 pass) and I manually booted the server to confirm the relay.deployed event shows up over /api/events.

registerApp, rotateAppKey and revokeApp now post their own app.registered / app.rotated / app.revoked events through postEvent, using an identity relay builds for itself (RELAY in src/actions.ts — role app, id relay). Each write is best-effort: wrapped so a refusal is logged and swallowed, never surfacing as the action's own failure. subject is the app id; summary names who acted and which app, e.g. "root registered Beacon" — no key or derived secret ever reaches the row (asserted in tests). The id relay is now reserved so no registered app can ever claim that source and forge relay's own events.

serve() posts one relay.deployed event right after the listener is up, subject the short commit, summary naming the environment, dedupe the commit — so a restart, crash loop or second process never repeats it, and a local run with no commit configured posts nothing. ServeOptions gained commit/where overrides (mirroring the existing ssh override) so tests can control dedupe deterministically. The terminal (src/tty.ts) never calls serve(), so it never posts.

Along the way I fixed a latent bug the rename exposed: the if (import.meta.main) boot log referenced the now-renamed where import and would have thrown at real startup.

README documents the new relay posts its own events behavior, the reserved relay id, and — per the issue's risk note — that naming the acting admin's username on the public timeline is a deliberate choice, not an oversight.

Not done: no route/page surfaces app.registered/etc. specially (they just show up in the existing timeline like any other event), and there's still no HTTP door for a real app to authenticate itself as role: "app" — that's a separate, already-flagged gap (README: "No route, page or terminal command reaches these actions yet").

Closes #33