app: traffic from a node whose adverts fail verification cannot be found or grouped #558

Investigation issue: decide what (if anything) to build before building it. Follow-up to #454/#478.

What happens today. When an Advert's Ed25519 signature does not verify, the app keeps the reception and refuses the identity: stripIdentity (app/src/meshpacket.js:62) empties the sender, and the claimed pubkey and name live exactly one console line long (app/src/app.js:572). After that:

• The HUD shows — as sender (app/src/hudsender.js:25).
• The row cannot become a target: feed.js:93 skips rows with a null sender_id.
• On the map, the only handle is the shared "Sender unknown" bucket (?unnamed=1, server/internal/httpapi/api.go:42), together with every other unattributable class.
• The raw frame is kept as evidence (app/src/capture.js:33), so the claimed identity is re-derivable after the fact, but nothing surfaces or groups by it.

The question. A node whose adverts keep failing still transmits. What if its claimed identity is exactly the identifier its traffic should be findable by? Today those receptions collapse into one anonymous bucket, indistinguishable from each other and from undecodable packets. For a hunting app that is a strange place to leave a transmitter you might want to drive toward.

The tension. The strip exists because the claimed identity is attacker-chosen (#356, #478): a forged name must never reach the registry surfaces, the pickers or the node estimates. Any handle for this traffic has to stay visibly "claimed, not verified" and out of every believed-identity path. Note also the verification limit (docs/2026-08-15-hop-count-trust.md): a replayed genuine advert verifies fine, so failing is not proof of forgery, and grouping must not become believing.

To investigate

1. Frequency and cause in real traffic: how often do signatures fail, and does the raw evidence say corruption or forgery? Does one failing node fail consistently (same claimed pubkey recurring)?
2. What the handle should be: the claimed pubkey marked unverified, a derived tag that groups without presenting the name, or nothing.
3. Where it surfaces: per reception at capture time (HUD), per row (ticker/receptions), as a selectable target, or only in the stored data.
4. Whether the answer changes per failure cause (corrupted in flight vs actually forged).

Related: #453 (HUD sender freezes at capture time), #451 (ticker shows a name with no id).