Changes touching this path

• checked against the live relay, and one path in the docs was never true: the mint instructions get what the check found (#831) Verified end to end rather than by reading, which is what the ticket asked for. A freshly minted identity was refused by the production relay, and the SAME key pushed successfully to a relay started with --allow <that hex> — the exact ExecStart shape setup-loot.js writes. The allowlisted half was proven against a LOCAL relay on purpose: the only way to prove it against production is to push a throwaway change into shared history that every peer then pulls forever. The three questions, answered: 1. LOOT_ALLOW_PUBKEYS still gates pushes exactly as claimed. setup-loot.js splits it, normalizes each key through toHexPubkey, and writes one --allow <hex> into the relay systemd unit; live /info lists precisely the two keys in .setup.env, and an unlisted key gets 403. 2. npm run setup:loot is still right, still node setup-loot.js, still from the scripts repo under PowerShell. 3. The clone path in docs/agents/identity.md was WRONG and had been for as long as it existed: it said ..\loot-<name>\<name>; the script clones into ..\loot-crew\<name>, one shared parent for every clone. The ticket inherited the error from the doc. Corrected, with the -Parent override named. Three things the check established that nobody had written down, now in both the script output and identity.md: * paste the ssh-ed25519 line AS PRINTED — setup-loot.js converts it to the hex the relay wants, so converting by hand is unnecessary; * skipping the manual step fails at PUSH, never at clone (reads are ungated), with a 403 and not a 401 since #865 — minutes later, in a different directory, from a different command, which is exactly how this rots; * GET /info is the self-service confirmation and the refusal names it: the relay publishes allowed_pubkeys as hex, so did-my-key-land is answerable without asking anyone. Two defects found on the way and filed rather than folded in: #966 (loot clone failed once with a bare http: error decoding response body and succeeded on retry — names no request, no remedy, and blames the codec) and #967 (loot new in a fresh clone warns that other sessions share the tree and points at loot lane new, both false in a clone). No relay deploy, no .setup.env edit, nothing added to the production allowlist: /info still lists the same two keys, and the throwaway clone and local relay are gone. d433ef9b · dbf3dbe6…

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.