Ben Meadors f57ee0bd71 fix(mesh): restore the implicit ACK for our own overheard PKI DMs (#11502) ...

* fix(mesh): restore the implicit ACK for our own overheard PKI DMs

A DM we originate is PKI-encrypted to the recipient, so when we overhear it
being rebroadcast we cannot decrypt it. perhapsHandleReceived() classifies it
DECODE_OPAQUE and returns before shouldFilterReceived() runs, which is where
the implicit ACK for our own transmission is generated. The client therefore
never receives the ROUTING_APP ack it renders as "Delivered to mesh" for a DM,
and the message sits in "sending" until it either succeeds outright or times
out as max retransmissions.

The ACK only needs the packet header (from/id), not the decoded payload, so
split it out of shouldFilterReceived() into
perhapsGenerateImplicitAckForOwnOverheard() and also call it from the opaque
short-circuit for packets that are from us. Behavior on the decodable path is
unchanged.

Broadcasts on a PSK channel decode normally and always reached the generator,
which is why channel messages were unaffected and only DMs showed the symptom.

* test: rename implicit-ack tests to avoid a trufflehog false positive

The camelCase identifiers tripped trunk's trufflehog/Lob secret detector.

* test: shorten one test name past trunk's Lob secret-detector pattern

trufflehog's Lob rule matches test_ followed by exactly 35 word characters,
which both new test names happened to hit. Unrelated to the fix.

2026-08-14 12:15:31 -05:00

..

test_main.cpp

fix(mesh): restore the implicit ACK for our own overheard PKI DMs (#11502)

2026-08-14 12:15:31 -05:00