Identity audit: leads post under unregistered handles; bind handles to canonical identities

[jaylfc]

Identity audit: every lead posts under a handle with no identity behind it

Jay asked for an audit ensuring each agent uses exactly one identity. The audit
found a bigger problem than duplicates.

What the audit found

Cross-checking 250 bus messages against the 35-entry registry:

Poster	msgs	registry
@taOS-dev	121	not in registry
@taOSmd-dev	40	not in registry
@taOS-website-dev	32	not in registry
taosc-dev	14	not in registry
hermes-20260608-153000	12	not in registry
hermes	5	not in registry
kilo / stepflash / northcode / laguna lanes	23	active identities

Only the free build lanes post under registered identities. Every lead,
starting with me, posts under a display string that resolves to nothing. The
registry holds taos-dev-20260718-013717; the bus has seen @taOS-dev 121 times.

Duplicate-identity check (the original ask):

• grok-taos holds TWO ACTIVE identities - -20260710-215816 and
  -20260711-000736. Genuine violation, needs one retired.
• taos-dev, taos-website-dev, taosmd-dev each have older identities
  correctly REVOKED after re-mint. Clean.
• hermes has three variants in play (two unregistered handles plus a registry
  identity holding the grants) - which is exactly why their SSE access looked
  broken tonight: the token they use is not the identity that holds the scope.

Why this matters more than it looks

Conversations are becoming memory (#2150). An audit trail whose participants
cannot be resolved to identities is a weak record - and it is the record the
product is being built around.

It also reframes tonight's spoof probe. I posted as @definitely-not-me to
demonstrate a gap. In truth the bus treats my everyday handle identically -
neither is registered, so there was never a distinction to break.

Decision (Jay): handles map to identities

Keep readable handles; require each to resolve to exactly one canonical identity.

1. Alias table: handle -> canonical_id, one identity per handle, one handle
   per identity. Issue tinyagentos.com: landing page + docs site (phase 1) #91 already proposes registry aliases - this is that,
   with a hard requirement attached.
2. Resolution endpoint so the bus and any client can resolve a handle.
3. Enforced at send once agent-send auth lands (@taOSmd-dev's tsk-fo7lxp):
   the authenticated identity must own the handle in from, or the send is
   refused. Until then, unregistered handles are tolerated and logged.
4. Backfill: register the handles already in use, bound to the identity that
   actually holds the grants. For hermes that means binding to the identity with
   the grants, not the one currently posting.
5. Retire the duplicate: grok-taos picks one active identity; the other is
   revoked.

Constraint

Do NOT rewrite history. Past messages keep the handle they were sent with; the
alias table lets them be resolved retrospectively where a binding exists, and
honestly reports "unresolvable" where none does. Nothing is deleted.