Fix Debug assert in IntervalTree's is_valid() with til::point keys

[steffen-heil-secforge]

assert(is_valid().first) in oss/interval_tree/IntervalTree.h fires in Debug builds whenever 64 or more URLs get autodetected on screen. for /l %i in (1,1,80) do @echo https://example.com/%i is enough to do it.

is_valid() seeds its bounds accumulators with std::numeric_limits<Scalar>::max()/::min(). We instantiate the tree with Scalar = til::point, which has no specialization, so the primary template hands back a default-constructed til::point{0,0} for both sentinels. The right-subtree check then asks {0,0} <= center, which is true for any real tree, so validation fails. 64 is the magic number because that's where the tree starts splitting into subtrees at all.

The fix is to stop needing sentinels — track emptiness explicitly instead. I also switched the max-stop accumulator from std::min to std::max, which is a separate upstream bug and the reason nobody upstream ever hit this: std::min pins that accumulator at numeric_limits<Scalar>::min() forever, so the left-subtree check (valid.second.second >= center) can never fire. You can see it by printing what is_valid() returns — for a tree whose real maximum stop is {10,99}, upstream's accumulator comes back as {INT32_MIN,INT32_MIN}. The right-subtree check reads the min-start accumulator and is unaffected.

That's also the trade-off against just specializing std::numeric_limits<til::point> and leaving this file alone (see @lhecker's comment below): that does fix the crash, but the max-stop accumulator stays dead, so the left-subtree constraint is never actually checked. Happy to go that route instead if you prefer the smaller footprint — it's your call.

Release builds were unaffected and the tree itself was always structurally valid — only the checker was wrong.

On editing a vendored file: MAINTAINER_README.md says take it wholesale and change nothing, so this needs an excuse. The file already isn't upstream's, though — every existing difference comes from ekg/intervaltree#31, opened by @PankajBhojwani in 2020 and vendored here 27 days later, still unmerged. Without it this doesn't compile against til::point at all, and it's also what made this bug reachable: it taught the constructor about struct keys but not is_valid(). Upstream's last commit was March 2021, so there's nothing to wait for. Both deviations are now written down in the README, along with a warning that re-importing wholesale will break the build.

Two things I left alone but can fold in: cgmanifest.json pins a hash whose content doesn't match the file, and I haven't reported the std::min bug upstream.

Built and tested locally, Debug|x64: the new IntervalTreeTests pass (2/2), and the full til suite is 280/280 with no regressions. Reverting just the header makes the new test hit the assert, though it does so by blocking on the assert dialog rather than failing cleanly.

Closes #20486

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[lhecker]

Can you edit the PR description to have a bit more of a human touch? It's longer than the diff lol.

[steffen-heil-secforge]

Ha, fair. Trimmed it by half and cut the bullet-point wall — the vendored-file justification and the "I couldn't build this on Windows" caveat are the two bits I kept, since I figured you'd want both up front.

[lhecker]

As discussed, I'd prefer a specialization of til::point, til::size and so on. Regardless, this is an excellent find. Thank you for it!

[steffen-heil-secforge]

Done — specialized numeric_limits for til::point and til::size, reverted the interval_tree change, and added <limits> to LibraryIncludes since it wasn't pulled in reliably. Kept a short note in the README about the pre-existing ekg#31 deviation. Let me know if you want other til types covered. Verified Debug|x64 locally: til suite 281/281.

And sorry for having Claude write the texts. I do review them (code and messages), but his English is better than mine, and more precise.