Implement Item 1 from gmp_gap_analysis.md

[mborland]

Summary

Implements item 1 of tests/beman/big_int/perf/gmp_gap_analysis.md: cut the fixed per-call front-end cost of + - << >>, small *, and small division. The public API is unchanged and big_int keeps its one-limb inline storage. On x64, small-operand calls are 10-35% faster. On M4, shifts, mul and div
are 11-39% faster, while small add/sub is flat (within about 1 ns either way). Two bugs that produced wrong values are fixed along the way.

Changes

• Move-assign steals the source buffer. c = a op b no longer copies the result limbs into c and frees the temporary's buffer. Allocator rules are respected: the buffer is stolen only when the destination's allocator can free it (propagating, always-equal, or comparing equal at runtime).
• No dead zero-fills.
  • New storage_for_overwrite(n) allocates without copying or zeroing. Debug builds poison-fill new blocks; constant evaluation still constructs every limb.
  • The multiply/divide dispatchers no longer need a pre-zeroed result buffer. The tiers that accumulate now zero their own output, which removes the double fill from basecase multiplies.
• add/sub. +=, -= and c = a +/- b run one pass through new add_n_tail/sub_n_tail primitives that stop once the carry dies. Signs are known without a zero scan, the result is trimmed once, and single-limb operands take a fast path.
• Shifts. c = a << s and c = a >> s build the result from the source in one pass (lshift_copy/rshift_copy) into an exactly sized buffer. <<= and >>= shift in place in one pass and no longer reserve a spare limb they don't need.
• Multiply. multiply_into writes directly into the result. *= keeps the destination's capacity and allocator: a one-limb multiplier runs in place, products up to 64 limbs go through a stack buffer, larger ones into a fresh buffer. A header-side basecase entry, multiply_basecase_runtime, skips
  the scratch hooks and the tier ladder when min(la, lb) < 32. It can be disabled with mul_header_basecase_enabled.
• Divide. Small shapes use a 128-limb stack scratch arena instead of the heap. The remainder is built at its exact size. A 2x1 quotient that fits inline doesn't allocate. /= and %= keep the capacity and allocator, and divide in place in the schoolbook band.
• Codegen fixes.
  • mul_add_single_limb_in_place keeps the 128-bit product in registers. GCC spilled it to the stack on every limb; decimal from_chars at 2000 limbs is 10% faster on x64.
  • Under GCC, the add/sub and shift loops use the shapes GCC compiles well: the simple carry loop and register-carried shifts. Clang and MSVC keep the unrolled and two-load forms.

Bug fixes

• Base 8/32 from_chars into a reused heap big_int combined new digits with stale high limbs and returned a wrong value.

• When the inline capacity is above one limb (basic_big_int<128> and wider), set_zero, >>=, %= and div_rem_to_zero(small, large) left stale inline limbs, so == against built-in integers could be wrong.

• Copy/move assignment with a propagating, unequal allocator kept a heap buffer it could no longer free with the right allocator.

Behavior change

A move-assigned destination now takes the source's heap buffer even when it already has enough capacity of its own, matching std::vector. Allocation.MoveAssignReusesDstStorageWhenLarger is inverted to MoveAssignStealsHeapSrcEvenWhenDstLarger.

Results (ns, median of 4 interleaved runs, before -> after)

x64 = i9-11900K, g++-14 -march=native, pinned. M4 = Apple M4 Max, AppleClang.

op	x64	M4
c = a + b, 1 limb	8.2 -> 5.4	6.9 -> 5.9
c = a + b, 16 limbs	25.3 -> 21.1	16.4 -> 17.7
c = a + b, 1024 limbs	842 -> 599	565 -> 450
c = a << 13, 16 limbs	24.6 -> 16.8	21.5 -> 16.1
c = a << 13, 2000 limbs	917 -> 773	654 -> 260
c = a * b, 2x2	28.2 -> 18.9	30.5 -> 18.6
c = a * b, 16x16	102 -> 89	95 -> 83
divrem 8x4	113 -> 94	96 -> 76
c = a + b, 16384 limbs	-37%	-23%

Allocations per call: c *= b 1 -> 0, c /= b 3 -> 0, c %= b 2 -> 0, a / b and a % b 2 -> 1, div_rem_to_zero 4 -> 2 (8x4 limbs, big_int). Medium and large multiply/divide/conversion rows are within about 3%.

Known gaps (follow-ups for item 2)

• On x64 with GCC, in-place shifts at 256 limbs and up are 5-8% slower than before. Neither of the two loop variants measured on GCC beat the old in-place loop.
• On M4, c = a + b at 2 and 16 limbs is about 1 ns slower (the 16-limb row is in the table above). A few in-place add/sub rows on both machines are 0.2-0.6 ns slower.
• c = a + b still costs 4-6 ns beyond its unavoidable malloc/free on small operands, and divrem 8x4 costs 15-26 ns beyond its allocations.

Testing

• New tests:
  • inline_tail
  • span_primitives
  • front_end_add_sub and front_end_shift: checked against a limb-level reference
  • muldiv_frontend
  • dispatch_contract: poisoned result buffers across every multiply/divide cutoff
  • alloc_count: allocations per operation across five allocator/inline-capacity setups
• Extended allocation.test.cpp.
• Passing configs:
  • AppleClang debug (ASan + UBSan), release and release-namespace
  • x64 clang-23 debug (ASan + UBSan) and release; g++-13 and g++-14 release; g++-14 debug; IFMA=OFF
  • Docker linux/arm64 GCC release and debug
• The 32-bit-limb build has no new failures.
• Full results, the inline-capacity study and the benchmark method are in tests/beman/big_int/perf/item1_frontend_results.md.