feat: configurable radius for !path hash-collision disambiguation

[sg]

What changed

• New config setting [bot] path_collision_radius_miles (miles, default 150, 0 = off) used only to disambiguate !path hop-hash collisions.
• When a path-hop hash matches more than one repeater, the nearest located candidate to a trusted anchor is accepted only if within the radius — a single-hop RF sanity bound. This keeps a correctly-located local hop even when it's the only located candidate, while still rejecting a far repeater that merely shares the hash (tropospheric ducting).
• 0 disables the bound (collisions then resolve only when ≥2 candidates are located — the previous conservative behavior).

Why

The prior fix (#29) dropped a colliding hop whenever fewer than two candidates had a location — which also discarded a correctly located local repeater when its colliding neighbour was geoless (a regression for that case). A bounded distance check restores it without re-admitting the far impostor.

Anchors

The bound is measured to any trusted anchor: the bot's own location, the message sender, or any unambiguously-located neighbouring hop in the path. So the bot's own location helps but is not required — a single cleanly-resolved hop is enough to disambiguate its colliding neighbours. With no anchor at all, collisions stay unlocated.

Notes

• Config-only (read at command time); no DB/!adm/web surface.
• Tests added to tests/test_path_resolve.py: lone local hop within radius kept; radius gates accept/reject (150 vs 50 vs 0); radius 0 still disambiguates ≥2 located; neighbour-hop anchors a collision with no bot/sender location.

Breaking changes

None. Default 150 mi; output format unchanged.