fix(query): correct frontier trimming in shortest path

[Schwarf]

Description

Fix incorrect frontier trimming in shortest path queries when maxfrontiersize
is set.

Previously, the code used pq.Pop() to trim the priority queue. This removes
the last element of the heap rather than the highest-cost
element, which can discard valid low-cost candidates and lead to incorrect
shortest-path results.

The fix replaces slice-based removal with heap.Remove of the maximum-cost
element.

Applied in both:

• shortestPath
• runKShortestPaths

A regression unit test has been added to ensure the highest-cost element is
removed when trimming.

Fixes #9577

[Schwarf]

Hi @themavik,
Thanks for pointing this out.

From what I see, both PRs fix the same underlying issue (removing an arbitrary element instead of the highest-cost one), but they differ slightly in eviction policy:

• This PR uses push-then-trim, so the newly discovered node is considered before evicting the worst element.
• fix(query): evict highest-cost node when MaxFrontierSize exceeded in shortest path #9607 keeps the existing structure and does trim-before-push with removeMax().

My understanding is that push-then-trim better preserves the intended frontier under a size cap, because it effectively keeps the best M elements from old_frontier ∪ {new_node}. A trim-before-push policy makes the eviction decision without considering the new candidate, which can drop a better existing entry while keeping a worse new one.

In addition, this PR includes a regression test (query/shortest_test.go) to guard this behavior.

That said, I’m happy to align with whichever eviction policy you prefer, or close this PR and contribute the test to #9607 if that’s the direction you’d like to take.