Send flood ACK on DM retries

[Stempit]

Improve DM ACK delivery on weak / asymmetric links

Problem

On weak or asymmetric links (and with moving nodes) direct messages ACKs often have a low delivery rate. The message itself gets through, but the ACK sent back along the reverse path does not. The sender keeps retrying and the recipient keeps replying with ACKs, yet none of them arrive, so the sender shows the message as undelivered even though it was actually delivered.

The root cause: once a path is established, the recipient always sends the ACK back along the stored reverse path. If that reverse direction doesn't work (asymmetric link), every ACK (including the ones for retries) goes down the same dead path.

Change

When a message arrives as a retry (meaning the sender didn't receive the ACK for the previous attempt), the recipient sends the ACK by flood instead of along the failing saved path. Flooding reaches the sender by any working route.

The first attempt still uses a normal direct ACK, so nothing changes on healthy links. The flood only happens when the direct ACK has already failed. The retry is detected from the message's existing attempt counter, so there is no new field, config, or protocol change.

Current flow:

A --DM(attempt 0)--> B      ✓ delivered
A <--ACK(reverse path)-- B  ✗ lost (reverse path broken)

A times out, retransmits:

A --DM(attempt 1)--> B      ✓ delivered AGAIN
A <--ACK(reverse path)-- B  ✗ lost AGAIN (same broken path)

And every retry's ACK goes down the same dead reverse path.
And result shows "NOT DELIVERED", but B actually got it.

With this changes:

A --DM(attempt 0)--> B      ✓ delivered
A <--ACK(reverse path)-- B  ✗ lost (first attempt, still saved path)

A times out, retransmits:

A --DM(attempt 1)--> B      ✓ delivered; B sees attempt>0 = "retry"
A <==ACK(flood)== B         ✓ reaches A by ANY working route

Result: A marks DELIVERED, stops retrying

Yes, this adds some flood load. But only one tiny ACK packet, and only on a retry.
In practice it reduces load overall: now some people work around the poor ACK rate by using a private channel for two people instead of DMs, and channel messages generate more flood traffic than a single ACK.

I tested this change in my city and found that It noticeably improves DM delivery confirmation and the overall DM experience.

And the same changes applies to the other roles that generate DM ACKs:

• Repeaters (admin CLI commands are sent as DMs)
• Room servers (receive client DMs and ACK them)