feat: restore reach-by-username with invites and a signed directory

[bahdotsh]

What this is

PR #331 re-keyed the Nostr routing tag from SHA-256(username) to
SHA-256(address), correctly: the old preimage was guessable, so anyone who
could guess a name could watch that inbox. The cost was cold contact, because
the tag's preimage became a value you can only learn from the peer, which is
exactly what "we have never spoken" means you do not have.

The machinery was never broken. Given an address, every hop already worked.
Only the first one was missing, and this adds it.

Two hops. A signed DiscoveryRecordV1 sits at a username-derived tag and
hands back {address, pubkey}; from there it is the existing
published-key-package path, untouched. The record cannot lie about a key,
because derive(pubkey) == address is checked the same way every control
frame is. It can only lie about a name.

Two paths, and invites are the primary one. createInvite() /
parseInvite() produce and verify a self-certifying blob, checkable offline
before create(). That is not a stopgap for discovery: the out-of-band
confirmation a scanned code represents is the only trust anchor the
directory has, so removing invites would remove its security model.

The API shape is the security control

Anyone may claim any name, so a username resolves to a set, always, even
for a single-device user (a phone and a laptop are two genuine claims). The
whole set arrives as one username_resolved event: no ranking, no "best"
claim, no per-claim event to race.

That shape is deliberate. A per-claim stream would make "take the first" the
easiest thing an app could write, and an app that auto-picks has quietly
turned a non-authoritative directory into an authoritative-looking one. Its
user then believes the name was verified when only a key ever was.

Discovery is off by default and additionally requires cold contact
(a claim pointing at an address with no published key packages resolves and
then dead-ends one hop later, so the two are coupled in the transport rather
than merely documented).

The bug class this closes structurally

publication_slot_id became a SyntheticPublication enum
(KeyPackage / Discovery / Deletion). Adding a second record type to the
send queue is exactly the change that half-wires: consult the discriminator at
three of four sites and publication outcomes start poisoning DORS reliability
scoring, silently. That bug has shipped here once already (PR #289).

Now all four sites match on a variant, so a third record kind fails to
compile at each of them rather than scoring itself as delivery.

Deviations from the design record, both deliberate

1. A third Deletion discriminator exists, because a NIP-09 deletion also
   rides the send queue and must stay out of the delivery metrics.
2. Resolution accumulates engine-side and emits one event at
   end-of-stored-events, with a tick-driven timeout sweep as backstop, rather
   than emitting per claim. See the API-shape reasoning above; the record
   names auto-selection as risk 1.

Verification

• 2197 tests green (cargo test --workspace, including doctests)
• cargo clippy --workspace -- -D warnings clean
• cargo fmt --all -- --check clean
• RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps clean
• tsc clean; JS harness 15/15
• All four binding sets regenerated together and verified idempotent
• THIRD-PARTY-NOTICES.md regenerated; license/README/NIP-44 guards pass

All six test obligations the design record names are covered and
negative-controlled by mutation: the four-domain non-prefix pin, the
re-authored-record refusal (nostr_author binding), address-shaped usernames
refused, discovery tag != address tag, resolution returning every claimant
with two devices of one user in the fixture, and the DORS metrics exclusion.

One of my own tests was found weak by its mutation: the original set test
passed when claims were keyed by address instead of by publisher, because the
fixture did not distinguish the two. test_username_resolution_keys_claims_by_publisher_not_by_address
was added and fails under that mutation.

Golden vectors were computed by an independent Python implementation
(BIP-350 reference bech32m, cryptography Ed25519, secp256k1 from the curve
equation, RFC 5869 HKDF), not by pasting encoder output. That script was
itself validated by reproducing the three already-shipped
test_routing_tag_golden_values literals.

Reviewer notes

• New runtime dependency: unicode-normalization (plus tinyvec,
  tinyvec_macros) for the NFC the record specifies. It is the only part of
  this with a binary-size cost, and this repo has a minisize profile that
  cares. An ASCII-only username policy would remove it entirely and close the
  homograph hole the record calls its least-defended surface, at the cost of
  narrowing the spec. Worth measuring before release.
• Kind 30777 is unregistered. Nothing in the NIPs registry is assigned
  anywhere in 30700-30800 (re-checked 2026-08-17). Recorded as an open
  question in the spec chapter.
• No iOS test covers the new config flag, because
  OfflineProtocolModule.swift is excluded from the Swift test target. Same
  gap nostrColdContactEnabled already has; not a regression.
• Nothing has run against a live relay. That is item 1's territory, and
  this adds a fifth thing for its relay leg to watch.

Wire format, verification order and threat model:
docs/spec/username-discovery.md.