the notify sidecar stops trusting whoever reaches it

to send one message to four accounts an hour ago i found the sidecar's
ephemeral port and POSTed to it directly, once per user, with no
authentication of any kind. that worked, which was the problem: the same
door was open to anything else on the machine, including a commander with
a shell.

two changes.

POST /api/notify/broadcast, owner only via `ownerOnly` on the permission —
the supported way to say one thing to everyone. teams will narrow it later;
today the choice is everyone or one person.

and the sidecar now requires a secret on everything under /_officer/. it
is generated per boot, held in memory, announced to the platform over the
registration socket beside the port, and never written to disk.

X-Officer-User could not carry this on its own, and my first attempt got
that wrong: it says WHO is asking, and a caller on loopback can write it
itself. only the secret says the PLATFORM is asking. so the check covers
the whole /_officer/ surface rather than just the send route — /_officer/
devices takes the same header to decide whose phones are listed and
deleted.

what it bounds, honestly: a MEMBER's commander runs as its own Linux user
and cannot read this process, so for every account but the owner's this is
kernel-enforced. the owner's own commander runs as the owner, same as the
platform, and is not bounded by this and cannot be — the same reason
`execution` permissions are never grantable. the owner's decision, and
this is a real improvement rather than a boundary.

`bun run notify:test` posts to that port and will now be refused. it is a
developer CLI on a box where the platform is running; left to fail loudly
rather than given a way in.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

src/servers/api/chat/notify-push.ts

@@ -1,5 +1,5 @@
 import * as sidecar from '@@/sidecar-registry';
-import { getNotifyServerUrl } from '../notify/router';
+import { getNotifyServerUrl, notifyProducerHeaders } from '../notify/router';
 import { shouldNotify, type NotifyKind } from './notify-decision';
 
 // The phone half of the bell: the same signal the browser socket listens to, delivered to APNs/FCM.
@@ -32,16 +32,17 @@ export function registerChatPushNotifications(): void {
       if (!(await shouldNotify(userId, sessionKey, kind))) return;
 
       const base = getNotifyServerUrl();
+      const producer = notifyProducerHeaders();
       // The sidecar has not reported in — either it is starting, or push is not running on this install.
       // Not an error: the browser bell still works, and this is the channel that is allowed to be absent.
-      if (!base) return;
+      if (!base || !producer) return;
 
       // `id` is the session key so the device can deep-link straight to the conversation. It is an
       // opaque uuid, which is the only reason it may travel: NO title, and no message content, because
       // this payload is read by Apple and Google. See docs/push-notifications.md.
       await fetch(`${base}/_officer/notify`, {
         method: 'POST',
-        headers: { 'content-type': 'application/json', 'X-Officer-User': String(userId) },
+        headers: { 'content-type': 'application/json', 'X-Officer-User': String(userId), ...producer },
         body: JSON.stringify({ code: CODE_FOR[kind], userId, id: sessionKey }),
         signal: AbortSignal.timeout(10_000),
       });