The E2E fixture's neighbour graph yields no path-inspector candidates, so two assertions cannot run

[efiten]

/api/paths/inspect beam-searches the neighbour graph (cmd/server/path_inspect.go), so a prefix only produces a candidate when the node behind it is connected in that graph. On the CI fixture it produces none, whatever prefixes are used.

What was established while wiring tests/e2e/test-path-inspector-e2e.js in #2053:

• the prefixes are valid — the endpoint accepts them and answers 200, not 400
• the fixture's graph is not empty: 110 edges over 200 nodes in test-fixtures/e2e-fixture.db
• prefixes taken from a packet's recorded path_json return nothing, because those hops need not form an edge chain the search can walk
• prefixes taken from the graph itself (a repeater, then /api/nodes/:pk/neighbors twice) return 10 candidates against a populated instance and still none against the fixture

What was not established: why the search finds nothing in the fixture's graph. The likely remaining explanation is that it holds no chain scoring above the search's own thresholds (speculativeThreshold and the path-trust threshold in path_inspect.go), but that is a hypothesis, not a measurement.

Consequence

Two assertions cannot run in CI:

• Show on Map draws the route
• switching candidates replaces the prior route instead of stacking it (public/map.js clears routeLayer before drawing)

They were written and they pass against an instance with a real graph. In #2053 they were removed from the suite rather than shipped as skips, because a green suite with two quiet skips is the exact problem #2037 is about. So that code path currently has no CI coverage at all, which is honest but not good.

What would fix it

Seed a short chain into the fixture that the beam search will score: two or three repeaters with neighbor_edges between them, enough observations to clear the trust threshold, and positions so the drawn polyline has coordinates. Then restore the two assertions.

Worth checking while doing it whether the thresholds are the blocker, since if they are, the seeding has to satisfy them rather than merely add edges. EXPLAIN-style output is no help here; the useful evidence is the evidence.perHop[].trusted field the endpoint already returns.

Not urgent: the map side pane's other behaviour (present, collapsed, expands, submits) is covered, and the standalone Path Inspector page is covered by test-path-inspector-coverage-e2e.js.