While working on #828 I noticed a solving change related to signedness modification. Turns out that this is because we're mixing signed and unsigned values here:

The result of _input.get_cost_upper_bound() is unsigned so it's possible to have an underflow whenever route_job_insertions[i][j].eval.cost (signed value) is negative. Cost insertions should be positive in theory but in reality they may be negative whenever the triangular inequality is broken. This is quite rare but does happens in practice with real-life instances, and also with e.g. Solomon instances due to rounding precision.

There is no risk of crash, or providing a screwed solution, but we're discarding some (good) insertions options there so this piece of code does not always behave as intended.