feat(escrow): hold value against a platform handle nobody has claimed yet

[SupremaLex]

The app must let somebody send to @alice before @alice exists on chain. The
Bank cannot: its escrow is keyed by an account's immutable id, and a sender who
knows only a handle has no id to key on. So HandleEscrow keys by the handle.

A new contract, not a change to the Bank diamond. Two state-changing
functions and one mapping do not warrant LibDiamond, a facet set, a BankInit
and hand-rolled modifiers — and the point of this contract is that it is not
part of the transfer stack. It takes the IdentityNames shape: UUPS behind
ERC1967Proxy, Ownable2Step, the transient reentrancy guard.

The escrow is for one window only

A deposit for a handle that already resolves is paid straight through to its
holder. Once an account has claimed its identity, holding the value would only
add a claim transaction to reach the same wallet.

Deposited and Forwarded are separate events because an indexer must tell
"this is waiting" from "this was delivered", and no balance changed for it to
read. Forwarded reports what the holder gained, measured across the
transfer, so a fee-on-transfer token cannot leave the only record of a payment
overstating it.

Paying through makes a deposit depend on the recipient: a holder that cannot
receive value fails the call. That is the honest outcome — the sender learns,
instead of the value waiting in a slot only that same wallet could ever claim.

Decisions, and the consequences written down

The handle is the whole key. No deadline and no refund. Each consequence is
pinned by a test named as intent, not left to be discovered:

• a platform that recycles a handle hands the new holder whatever accumulated
  for the previous one;
• after a rename the slot waits for whoever proves the freed handle next, which
  may be a different account;
• neither the depositor nor the owner can take a deposit back.

The key, which is the load-bearing part

The slot comes from a rules-independent form of the text — trim spaces, drop
one leading at-sign, fold A–Z — so an owner reconfiguring a platform's
normalization cannot move money already held. The text is separately
validated against the platform's current rules on the way in, so nothing funds a
slot no proof could ever claim.

Immunity from re-keying is not immunity from stranding, and the header says
so: a claim is authorized by resolveHandle, which normalizes under the rules of
the moment, so an owner who narrows a platform makes the affected handles resolve
to nobody and their value waits, at the same key, until compatible rules return.
A test narrows X after a deposit and pins both halves.

The at-sign is dropped, exactly as stripLeadingAt does, rather than
refused. That is safe for every expressible Rules — a non-email platform
refuses 0x40 outright, an email needs a name part before its @ — so no
platform can accept a handle beginning with one, and both spellings reach a
single slot instead of splitting one identity's money across two keys. The lemma
is checked across all 44 rows of HandleVectors with no row skipped, and the
slot derivation is pinned by a literal computed from the formula rather than read
back out of the contract; Python and Rust both reproduce it.

The validation needs the rules, so IdentityNames gains rulesOf. Without it
the escrow either accepts text that can never resolve — and there is no refund —
or keeps its own copy of the rules and disagrees with the naming system the first
time setPlatform runs. resolveHandle cannot answer the question: it returns
the zero address both for a handle nobody holds and for text nobody could hold,
and those two must not be confused when money is about to move.

The transform, unlike the rules, is pinned here at compile time. That is what
makes the key independent of configuration, and it means the naming system cannot
change its normalizer alone: such an upgrade has to carry an upgrade here, and a
Rules field appended there would be dropped by this decoder.

What review changed

An xhigh review found a real fund-loss bug and two false claims in the contract's
own comments. Worth reading closely, since the fixes shaped the design:

• claim validated the caller and never the destination. The zero address
  accepts a native transfer, so an unset recipient emptied the slot, burned the
  value and logged a success; this contract's own address emptied the books and
  left the value as surplus nothing points at. Neither is recoverable. Both are
  now refused.
• "The owner has no other way to reach a balance" was false. The naming
  owner installs a verifier it controls, binds any handle to itself and claims —
  two ordinary transactions, no upgrade, no proxy event. Not removable without
  the escrow ceasing to follow the naming system, so the header now states that
  the naming owner is part of this contract's trust base and that this is larger
  than a pause rather than a substitute for one.
• The rules-change promise overreached, as above.

Testing

870 tests. Thirteen guards proven red without their code, including claim not
checking the destination, the at-sign kept instead of folded, the ERC-20 payout
going nowhere, Forwarded reporting the requested amount, and the storage root
reordered under an upgrade.

The reentrancy tests reenter with calls that would succeed — a token that
deposits again from inside its own transfer, and a claimer that claims again from
inside its payout while somebody else's escrow sits alongside — and expect the
guard's own error rather than any revert. The upgrade test upgrades to a version
that appends a field and reads the old ones back through the new layout, so a
reordered field fails it; the byte-identical upgrade it replaced could not.

Notes

The mock verifier deliberately does not ship in the crate's artifacts: it
reports whatever a caller stages, so a copy reachable from a deploy tool is a way
to mint any identity on a live chain. The full deposit → bind → claim path is
covered in Solidity; the anvil test covers what Rust owns — the artifact deploys,
the binding shapes, the slot derivation, and the authorization refusal by name.

This branch touches IdentityNames.sol, Deploy.s.sol, anvil.rs,
artifacts.rs, vendor-artifacts.sh and codegen.mjs, all of which
feat/identity-bind-fee (#4) also touches. Whichever merges second needs a
rebase and a regeneration of the ABI and vendored artifacts.