[Security review][L1] Bound the receive wait and resend phase on a wall-clock deadline

[gistrec]

Problem

Both timeout loops decided when to give up from how long a single recvfrom
sat idle (SO_RCVTIMEO = 1s), not from real elapsed time. Any host sending
faster than once a second kept recvfrom returning data, so the idle countdown
never advanced and the loop ran forever. The session id is cleartext in every
broadcast, so a "valid" RESEND flood is as easy to forge as raw junk.

• Receiver — Receiver::run (src/Receiver.cpp): ttl decremented only on
  recvfrom < 0. A flood of one-byte junk (parseHeader → NotOurs, no ttl
  change) kept while (ttl > 0) alive indefinitely — directly contradicting the
  in-code comment that the timeout "stays reachable". Impact is low (a foreground
  CLI just keeps waiting), but the loop was genuinely unbounded.
• Sender — Sender::serveResends (src/Sender.cpp): ttl = ttl_max on any
  valid RESEND for our session, before the rate-limit. The only exit was
  ttl_max consecutive idle seconds, which a ≥1 RESEND/s flood prevents forever —
  the sender keeps re-reading the file from disk and (in broadcast mode)
  re-broadcasting parts to the whole segment. sent_part[part] also used
  operator[], inserting a node for every requested index.

Fix

Decide both timeouts on a steady_clock deadline that only real progress pushes
forward.

• Receiver: the main loop waits on receive_deadline, refreshed only by a
  recognised packet from our sender (ANNOUNCE/TRANSFER/FINISH for our session).
  Junk never pushes it, so the receiver still gives up ttl_max seconds after
  the last real packet. Per-packet transfer semantics (the ttl_max budget
  between packets) are unchanged. The recovery loop (checkParts) keeps its own
  per-round countdown and now resets it explicitly rather than inheriting the
  main loop's counter.
• Sender: serveResends gains an absolute phase deadline (ttl_max * 10,
  steady clock) fixed at phase start and never extended by incoming traffic, so a
  RESEND flood can no longer keep the phase running without end. ttl is now
  refreshed only when a part is actually re-sent, and the rate-limit map is
  probed with find() instead of operator[] so merely being asked about a part
  no longer inserts a node. The map stays bounded by the sender's own
  total_parts (its own file), which the attacker cannot inflate, so no hard map
  cap is needed on top of the deadline.

Tests

tests/e2e_flood.sh (+ tests/flood.py, registered in CMake, Python-gated like
the other proxy tests):

• receiver: a junk flood at the receive port — the receiver (--ttl 2) must
  still time out (exit 2) instead of hanging.
• sender: a flooder sniffs the sender's cleartext session id and hammers it
  with valid RESENDs — the sender must still stop at its resend deadline
  (exit 0) after actually serving resends.

Both scenarios hang on the pre-fix binary (verified against master) and
pass on this branch. Full suite (unit + all e2e) passes locally, including under
ASan/UBSan.

Notes

• Trusted-LAN, low severity: the practical win is that neither loop is unbounded
  anymore. RESEND_PHASE_TTL_MULTIPLE = 10 (150s at the default --ttl 15) is a
  generous backstop for real LAN recovery while keeping a single run finite; it
  scales with the operator's --ttl.
• Independent of the session-hijack fix branch; based on master.