Fix replies dropped when flood.max.unscoped is low

[ViezeVingertjes]

The repeater ignores the return path it already has, for logins only.
onPeerDataRecv checks client->out_path_len before falling back to flooding a REQ
reply. onAnonDataRecv never did: it only looked at reply_path_len, which
handleLoginReq does not set. A login arriving DIRECT is therefore always answered by
flooding, even when the repeater holds a valid out_path for that client.
simple_room_server already had this check; only the repeater was missing it.

Flooded replies go out un-scoped. A DIRECT request carries no transport codes, so
recv_pkt_region is NULL and sendFloodReply fell through to sendFlood(). Under
flood.max.unscoped=0 that reply dies at hop 0. Under the shipped default of 64 it
instead propagates across the whole mesh, which accounts for a lot of the REQ/RESP
flood traffic operators are seeing.

Changes

• chooseReplyRoute(): a login arriving DIRECT replies via the client's stored
  out_path, matching what every other request type already does.
• chooseReplyScope(): when the requester's scope cannot be determined, reply in the
  node's default Region instead of un-scoped. An un-scoped flood request is still
  answered un-scoped, so paths that work today are unchanged.
• Both are pure functions in src/helpers/RoutingPolicy.h, alongside
  isFloodHopLimitExceeded() extracted from the copy in each firmware.
• 14 unit tests in test/test_routing_policy/.

- Le Claude 🤖