Route refusal above MAX_VERTICES carries no bound, and the cap is not caller-controlled

[GeneralPawz]

Problem

axiolid_route::shortest_path refuses any input above MAX_VERTICES = 512 with RouteError::TooManyVertices. A consumer that must still answer for larger models has no way to get a partial or bounded answer from the kernel: the refusal is all-or-nothing.

A visibility graph is O(n^2) edges with O(n^3) construction, so a hard cap is the right instinct. The gap is that 512 is low for real building footprints, and there is no way to say "too big for an exact route, but here is a proven lower bound".

Why it matters

A refusal and a lower bound are different facts. Straight-line distance between endpoints is a valid, provable lower bound on any route: no path can be shorter. A consumer can act on that (report a minimum, defer, escalate) where a bare refusal forces it to either drop the query or reimplement routing.

Concretely: a consumer with a 2048-vertex budget and a conservative-degradation path cannot adopt the kernel without either shrinking its supported model size 4x or keeping its own implementation.

Proposal

Two independent changes, either useful alone:

1. Make the budget a caller parameter rather than a constant. The right cap depends on the caller time budget, not on the kernel.
2. Return a proven lower bound alongside the refusal, so an over-budget query still carries a usable fact rather than only an error.