bootstrap's mailOperational check certifies a path real mail no longer takes (unsigned probe, count-delta only) #382

Split out of the cli#380 design review so PR 3 there stays small. Raised by Kern; the argument is
his, the scoping is mine after checking the premise.

The gap

runHealthChecks() reports mailOperational: healthMail(...) (bootstrap.ts:238). That check
hand-builds an unsigned probe (from: "system:bootstrap", bootstrap.ts:180) and asserts on a
new/ file-count delta.

After cli#377, "mail is operational" means verified promotion: real mail is only presentable
from cur/ once it has passed the shared policy. So the health check certifies a path that real
mail no longer takes. It can report green on a host where every genuine message would dead-letter —
for example where FLAIR_URL is misconfigured, or a spoke lacks the sending agent's key.

That is a green light that lies, which is the class we keep paying for.

Why it is not simply "send a signed probe"

The obvious fix is to deliver a signed probe through promote() and require ok: true. Two things
block that today:

1. bootstrap.ts provisions no identity. It imports no identity module and creates no keypair
   (checked against 4ea6e44a — the imports are fs/path/crypto/os, sanitizer, workspace, nono,
   relay, config). packages/cli/src/utils/identity.ts has the machinery, but bootstrap does not
   use it. A signed probe therefore needs NEW identity provisioning in bootstrap.
2. system:bootstrap is not a Flair agent, so a naive migration gives getAgent → null with
   /Health OK → terminal invalid → mailOperational permanently red.

What cli#380 PR 3 does instead, and what is left here

PR 3 deletes bootstrap's gratuitous cur/ write (the count delta already proves delivery), kills
the spoofable from.startsWith("system:") prefix test in favour of matching the probe's own
randomUUID, and labels the result honestly as filesystem-only. That removes bootstrap as a cur/
writer and stops it overclaiming.

What remains is this issue: a bootstrap probe that exercises the real verified path. Options,
in the order I'd consider them:

• register a dedicated probe identity during bootstrap and send a signed probe through promote(),
  requiring ok: true;
• or keep the filesystem check and add a SEPARATE, clearly-named verified-delivery check, so the
  two cannot be confused;
• or state in the output that mail delivery is not proven by bootstrap and point at tps agent verify (cli#343 / ops-0ruq) as the thing that does prove it.

Acceptance, whichever is chosen: on a host where verification cannot succeed (bad FLAIR_URL, or a
missing sender key), the check must NOT report mail operational. That drill is the point.

Refs #380, #343