Routing: follow up scorpio810's review of #1245

- Rename the `near` lambda in Conductor::setPathPoints() to `isNear`:
  `near` and `far` are empty macros in the Windows headers (minwindef.h).
- Reword the log when setPathPoints() refuses a route. "does not join the
  two terminals" named only one of its reasons; the router always returns
  the two terminals and at least one exit point, so a refusal means the
  route is not a run of horizontal and vertical segments between them.
- README: running along another wire is penalised, not forbidden, so two
  wires can end up drawn on top of each other.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

misc/qet-mcp/README.md

@@ -543,8 +543,11 @@ Python, plus the hang guard on `addConductor` and the database refresh in
   the cheapest found by a search that charges for length, for each bend
   and, less heavily, for running along or crossing another wire. Obstacles
   are each symbol's own rectangle plus half a grid step; texts, images,
-  shapes and tables are not obstacles. The path is saved as a hand-edited
-  one, so it survives a reload and one undo puts the default back. Where
+  shapes and tables are not obstacles. Running along another wire costs
+  more but is not forbidden, so where there is no other way two wires
+  can end up drawn on top of each other. The path is saved as a
+  hand-edited one, so it survives a reload and one undo puts the
+  default back. Where
   no route exists, the wire keeps its path: `route_conductor` returns
   `"no-route"` and both ops say so in `note` -- it is not a failure, and
   the run goes on. Like a hand-edited path, it is stretched rather than