feat(app): name a short id only when the registries of the SF agree, and mark it as a guess

[khagele]

Closes #452

The problem

resolveName asked the configured registries in order and took the first that answered ambiguous: false. That flag is a claim about one registry: a second registry knowing the same 2-byte prefix under another name was never asked, so disagreement could not even be observed. A 2-byte relay hash is the forwarder's hash out of the path, one in 65,536 per registry, and the name it got reached the ticker and the HUD looking like a resolved identity (73s.be repeater_3_ on hash 2beb, 2026-08-22). Decisions and what stays a guess are in docs/2026-09-05-names-agree-or-nothing.md.

My changes in this PR

• resolversFor: every registry of the companion's spreading factor, asked at once; a registry of another SF names nodes this radio cannot hear, so it is left out. With the SF unknown, all are asked. Config order no longer means priority (orderResolvers is gone).
• consensusName: one registry knowing the prefix, or several agreeing, is a name. Two different names for one prefix is a refusal, cached as such even when a third registry was unreachable, because no retry can turn disagreement into a name. Silence with a registry unreachable is not cached, as before.
• The guess mark: isGuessedName and displayName in app/src/names.js; a name on a 2- or 3-byte id shows as ~name in the ticker (senderText), the HUD (senderReadout), the target list (targetParts) and the map popup. An advert's own name on its full key, a channel sender's name and an 8-byte discover prefix carry no mark; a 1-byte hash never carries a name.
• Changelog entry in both copies.

Cost

One request per registry of the SF per unknown id instead of one per id, bounded by the session cache and the in-flight coalescing of #230. With the two registries in config.example.json that is at most double.

Verification

Suite	Result
app vitest	908 passed, build and eslint clean
web vitest parity.test.js	57 passed

Tests with two stub resolvers, as the issue asked: two names for one prefix give none and the refusal is remembered; agreement gives the name, and so does one registry knowing it; only the resolvers of the companion SF are asked; silence with a registry down is not cached; disagreement with a registry down stays refused. Mutation-checked: consensus taking the first name, the SF filter removed, the guess floor at 16 hex and the refusal cache dropped each go red. Three existing tests that asserted an unmarked name on a 3-byte id now assert the mark.

Browser, two stub resolvers of SF 7, three receptions: both registries are asked for both prefixes; the ticker and the target list show 2beb (they disagreed), ~Agreed (they agreed) and alpha (an advert's own name, unmarked).

Not in this PR

• The map's web/names.js: the website resolves prefixes on its own terms and app/web disagree on sender identity in the node-position layer #296's rule for identities is unchanged.
• Agreement on the matched pubkey rather than the name: the resolvers' response is not relied on for it.

🤖 Generated with Claude Code