fix(app,web): hang a Discover-heard repeater's star from its own position

[khagele]

Closes #723

What

A Discover reply carries a prefix of the responder's key. The node layer paired it with the registry node whose key it alone starts (#661). The reach stars did not: starKey gave the prefix a star of its own, and positionOf looked it up as a whole key, which a prefix never is. So a repeater heard by Discover drew its ▲ and, beside it, a star hung from its RSSI estimate with the prefix as its name.

The pairing is now one function, registryMatcher(nodes) in nodelayer.js:

• groupSenderPointsForNodes uses it where it had the same loop inline;
• coverageStars takes it as registryNodeOf: a hearing whose own id names one registry node joins that node's star, keyed by its pubkey, under its ▲;
• a prefix that starts two keys or none keeps a star of its own from its estimate, as before;
• a relay, path or direct hash still goes through the attribution by reach first.

Both copies of nodelayer.js change the same way; coverage.js is copied whole. web/parity.test.js adds registryMatcher to the shared core and checks both surfaces name the same node. Amended in docs/2026-09-08-coverage-overview.md (point 8).

Effect on real data

On the /api/points export of 8 Aug to 7 Sep around Nijmegen: before, 5 of 66 stars hung from their ▲ and 61 from an estimate; after, 63 of 71 hang from their ▲ and 8 from an estimate. The total grows because a prefix with too few hearings for an estimate had no origin at all, and now hangs from its node.

Found while building the #666 export, which draws the stars as the map has them.

Verification

• coverage.test.js: a prefix's hearings join the node's star with its advert; a prefix that starts two keys keeps its own; a relay hash is left to the attribution. The first is red with the pairing removed.
• nodelayer.test.js: registryMatcher names the node for a discover prefix and an advert key, none for an ambiguous or unknown prefix, none for a relay hash.
• app: 1630 tests green, eslint clean, npm run build clean
• web: 763 tests green, eslint clean, full e2e 297 passed

🤖 Generated with Claude Code

[efiten]

Review before merge: one point to change, one question. #725, #726 and #729 sit on top of this one. Point 1's call sites checked at af00c86; the effect is read from the code, not run.

1. Dot hue and selection dimming still key a Discover hearing by its prefix (change requested)
coverageStars now keys a registry-matched Discover hearing by the node's full pubkey (coverage.js:202-204), but four callers still compute the key without registryNodeOf:

• app/src/huntmap.js:196 (pointHue) and :204 (ownerOf)
• web/map.js pointHue and owner in selectionDimmer (around lines 1642-1648)

For a discover_pubkey hearing they get the prefix, which no star has any more. In reach mode:

• coverageHue.get(prefix) misses, so those dots fall back to the tier colour while their rays carry the node's hue (the app,web: a coverage overview, every repeater's reach in its own hue, all at once #603 rule that dots take their repeater's hue).
• After a tap on the node's ▲, ownerOf returns the prefix, so the Discover dots and pillars dim to 0.25 while their rays stay lit.

Proposed: one starKeyOf(pt) in coverage.js that coverageStars, pointHue and ownerOf/owner all use, plus a test that a Discover hearing's key equals its star's id.

2. Question: the app pairs over two different node sets
huntmap.js:221 builds the matcher from all nodePositions; the node layer pairs over inView (:1058). A prefix unique in view but ambiguous across the registry is paired on the node layer and not in the stars. It needs two keys sharing an 8-byte prefix. Pair both over the same set, or note the difference in the doc?

[khagele]

Pushed 82588a0 for the review, rebased on master. Per point:

1. Dot hue and dimming. starKeyOf(pt, { attributionOf, registryNodeOf }) in coverage.js holds the rule; coverageStars builds its keys with it, and pointHue/ownerOf in huntmap.js and pointHue/owner in web/map.js ask it with the two functions the last draw's stars were built with. A test keys each hearing of the app,web: a repeater heard by Discover hangs its reach star from an estimate, beside its own ▲ #723 fixture (two Discover, one advert) and compares it with its star's id; red with starKeyOf reading only the reach. The amendment in docs/2026-09-08-coverage-overview.md names it.
2. Two node sets in the app. Should both pair over the same set? The stars pair over all node positions, the node layer over the nodes in view. Over all nodes the pairing does not change with the view; over the nodes in view it matches what the node layer shows. Or leave the code and note the difference in the doc?

App: 1637 tests, eslint, build. Web: 763 tests, eslint, Playwright 297 passed.