Use the authoritative key on the PKI decrypt path

[caveman99]

Targets this PR's branch (meshtastic#11050). The tier-3 change makes NodeDB::copyPublicKey fall through to the ephemeral TMM NodeInfo cache, and Router::perhapsDecode uses it to resolve the sender key on the inbound PKI-decrypt path. A DM decrypted with a cache-resolved TOFU key is then stamped pki_encrypted and attributed to p->from, so authenticated DM attribution rests partly on the opportunistic cache. This switches that one call to copyPublicKeyAuthoritative (hot/warm only); the outbound encrypt-to pool keeps the opportunistic lookup.

[NomDeTom]

Which intention is more important here:

1. making sure to use an authenticated PKI not TOFU (TOFU is still accepted from hot & warm stores)
2. making sure to avoid an extended search in the ephemeral store

If 1, we can gate the ephemeral key use to authoratative keys only (evicted hot/warm store that have been authenticated previously)

If 2, we can use NodeDB::copyPublicKey (not confirmed - clod suggested that)

Interestingly this did make me realise we call the same thing 3 names:

hot: nodeInfoLiteHasXeddsaSigned
warm: isVerifiedSigner
cache: keySignerProven

[NomDeTom]

addendum: keySignerProven is a double-role: manually verified or a xeddsa signer

[caveman99]

Intent 1 is the real driver. Intent 2 is mostly already handled: the copyPublicKey call sits behind the decrypt-candidate gate (p->channel==0 && isToUs && !broadcast && rawSize>overhead && ourNode has a key), so the ephemeral scan only runs for PKI-shaped packets addressed to us, not per packet. I would not let the search cost drive the design.

One precision on what this patch actually does: copyPublicKeyAuthoritative restricts to the authoritative tiers, not to authenticated keys. Hot and warm still hold TOFU keys, so it does not enforce 'PKI not TOFU'; it only stops the ephemeral superset from becoming a new key source for pki_encrypted attribution. That is a 'do not widen the TOFU surface into the cold tier' property, which is what I was after, but bluntly done.

If we want intent 1 properly, your option 1 is the better line: allow an ephemeral-cache key on the decrypt path only when it is signer-proven (keySignerProven). That keeps the cache useful for a previously-authenticated node evicted from both hot and warm, while never letting a cache-only unverified TOFU key back an authenticated DM. Outbound encrypt-to should stay opportunistic (worst case is we cannot reach a long-tail node), which is why the p->to lookup is intentionally left on copyPublicKey. Happy to change this PR to gate on signer-proven instead of authoritative-only if you prefer that line.

Strong +1 on unifying the three names. nodeInfoLiteHasXeddsaSigned / isVerifiedSigner / keySignerProven are one concept per tier, and the earlier hot-only gate bug was exactly a tier mismatch between them. A single predicate (extend isVerifiedSignerForKey to also consult the cache) would make 'is this key a verified binding for this node' answerable in one place. The dual role of keySignerProven (manually verified or xeddsa signer) is fine and is the right meaning for that unified predicate: both are strong enough bindings for DM attribution.

[caveman99]

Base PR meshtastic#11050 merged into meshtastic/firmware develop, so re-targeted upstream as meshtastic#11116. Closing this one.