The existing guard stopped at the bridge's injector, so it proved inheritance
but not that the override survives what the repeater actually does with a
packet. This adds the missing leg: a real core Dispatcher, a real
RepeaterHandler engine and a real PacketRouter, with only the radio and the
daemon container substituted. The assertion is on the bytes read back off the
radio.
The conflict is made real rather than notional. Both the companion's default
scope and the dispatcher's are set to the repeater's own region, so without
the override that region is what goes out -- asserted by a control test that
sends the same message on the same channel with no override and finds the
repeater's code on the air. Only the override differs between the two.
Verified by mutation rather than by assuming: neutering
`_apply_explicit_flood_scope` so it falls back to the node's resolver fails
the integration test while leaving the control passing, so the test is
sensitive to the thing it names and not merely to "something got scoped".
A second mutation settles the marker question the previous commit reworded.
Clearing `_flood_scope_applied` while keeping the scoping leaves the
integration test green and fails only the assertion on the mark itself,
confirming the transport code is protected by the route change alone.
The fake radio returns a metadata dict because that is what the shipped
wrappers do. A bare True crashes the engine at `tx_metadata.get(...)` after
the bytes are already on the air -- harmless here since sx1262 and kiss_modem
both return dicts, but it would have masked a real failure behind an
apparently successful send.
agessaman
71837f214c