maintenance: handle geometric repack tasks with promisor pack(s)

The geometric-repack maintenance task predates support for keeping promisor packs in their own geometric progression. After that support was added in dcc9c7ef47 (builtin/repack: handle promisor packs with geometric repacking, 2026-01-05), the maintenance task still made two decisions from the ordinary-pack progression alone:

- whether an explicit run should use --geometric or its all-into-one fallback; and

- whether --auto sees enough work to run the task at all.

That can make partial clones rewrite more than necessary. If the ordinary packs would all be rolled up, the task can choose the all-into-one path even when the promisor progression would leave a large pack alone. Likewise, an all-promisor repository can have a promisor rollup ready while --auto sees neither an ordinary split nor enough loose objects and skips the task.

The first patch makes the repack-mode choice consider both progressions. It keeps the all-into-one fallback only when neither progression leaves a pack above its split, so the fallback does not rewrite packs that geometric repack would have kept.

The second patch makes the --auto condition consider geometry.promisor_split alongside geometry.split. A non-zero split on either side means that geometric repack can combine at least two packs.

Both tests build three promisor packs whose object counts cause the two smaller packs to roll up while leaving the large pack intact. The --auto test uses a high loose-object threshold, so the promisor split is the only reason the task runs.

Thanks in advance for your review!

Taylor Blau (2):
maintenance: account for promisor pack geometry
maintenance: trigger --auto for promisor rollups

 builtin/gc.c                  |  5 +--
 t/t5331-pack-objects-stdin.sh |  3 +-
 t/t7900-maintenance.sh        | 68 +++++++++++++++++++++++++++++++++++
 3 files changed, 73 insertions(+), 3 deletions(-)

base-commit: a97fcc37c2bc6340a8d7ce78dedf227aac4e9aa7

2.55.0.483.gdc2fffc37c