src/add/hub.bend fails

add/hub: ez add <name>@<version> as a pure planner, for a target bend reads as a hub package's name (Tgt.aim). It reads the same World as the git planner (add/world.bend), and asks the lock's own questions of the hub the ledger names (lock/world.bend): what the name names (W.Name), then that package's manifest and files (W.Pkg). Their answers are the World's hubs.

Before it asks anything the planner refuses what needs no answer: no ledger, one that does not parse, a ref and an entry both given (a name pins its version, so the word after it is the entry), and a key the ledger alone refuses (Named.hub.why). Then it asks at most two rounds: the name, then the package it names. The hub's answer must be a 0x name, and the package is judged as ez lock judges a hub package (W.hub.how): its manifest hashes to that name, no path leaves it, each file hashes to its sum, and the files hash to the name (EZ-HASH-3).

With the package in hand, the entry is the one given, which the package must hold, else its main.bend, else its first top-level .bend file in manifest order, else none. The key is Named.hub.key's: --rename, else the key the ledger gives this name part, else the name part itself. The plan of an add that succeeds, in order: the tree laid under $BEND_LIB; the name's file, $BEND_LIB/names/<name>@<version>, so bend reads the name without asking the hub; ez.toml written with [deps.<key>] holding hub and hash; .gitignore when the allowlist changes; and the lines a person is told, the hash the name names and, when there is an entry, the import line. A refusal has no effect at all. ez add writes no lock, for a name as for a git package: the next ez lock reads the name from ez.toml and asks the hub nothing (EZ-HUB-2).