commit-reach: terminate merge-base walk when one paint side is exhausted

[spkrka]

Optimize paint_down_to_common() for merge-base queries that hit
large one-sided histories.

When the walk from one side reaches a commit with a very low
generation number that the other side never paints, max_nonstale
stays alive and forces the walk to drain most of the graph. A
common trigger is a repository import that grafts a separate
history with its own root, but any merge that introduces a
low-generation commit never painted by the other side has the
same effect.

A new merge-base candidate can only be discovered when exclusive
PARENT1 and PARENT2 paint meet. This series teaches
paint_down_to_common() to stop as soon as one side has no exclusive
commits left in the queue; once one side is exhausted, no further
candidates can appear.

  origin/HEAD  o   o  PR HEAD
               |   |
     (import)  o   :
              / \ /
             |   o  merge-base
             |   |
             :   :  (~2.5M commits)
             |   |
  import root   main root

This was discussed in an earlier RFC thread [1]. Derrick Stolee
provided a criss-cross counterexample that sharpened the halt
condition, and Elijah Newren independently discovered the same
optimization and shared an implementation in PR #2150 [2]. Patch 3
incorporates test cases from Elijah's branch.

This series implements the optimization only after the walk enters
the finite-generation region, where generation ordering guarantees
that paint on visited commits is final.

Patch organization

1/5 commit-reach: introduce struct paint_queue with per-side counters
2/5 commit-reach: stop the walk when one side is exhausted
3/5 t6600: add side-exhaustion edge-case tests
4/5 t6099, t6600: add side-exhaustion regression tests
5/5 Documentation/technical: document paint_down_to_common()

Patch 5 adds a technical document covering the algorithm, the
INFINITY/finite region boundary, and the termination conditions,
to help reviewers and future contributors follow the reasoning.

Benchmarks

Measured on a 2.6M-commit monorepo with commit-graph (baseline
v2.55-rc1):

merge-base --all  (across import)       4.293s ->    8ms  (537x)
merge-tree        (across import)       5.345s ->   13ms  (411x)
merge-base --all  (1000 commits apart)  5.404s ->    7ms  (772x)

No regression on linux.git (1.4M commits, commit-graph):

merge-base HEAD HEAD~1000                 38ms ->   40ms
merge-base --all HEAD HEAD~1000           87ms ->   36ms
merge-base --is-ancestor HEAD~1000 HEAD   11ms ->   11ms
merge-base --all HEAD HEAD~10000         626ms ->  428ms

[1] https://lore.kernel.org/git/CAL71e4Ps-2_0+uuZu43N9pFnXBemoAohPs_eyRJf8taXHJPAXQ@mail.gmail.com/T/#u
[2] #2150