GNU GMP 6.3.0 Mini-GMP allocation metadata range issue

Status: FINDING + VALIDATED FIX on the recorded AArch64 environment.
Additional x86_64 targeted validation: PASS.

Finding commit:
22d004b059574779da2d321918d2767a6a6f5c36

Public evidence:
https://github.com/frenchcryptonad-max/linux-arm64-build-findings/tree/main/findings/gmp-6.3.0/mini-gmp-mpz-init2-int-overflow

Problem summary:
mini-gmp computes allocation sizes in mp_size_t (64-bit on the tested LP64
systems) but stores allocation metadata in int. Requests at INT_MAX+1 limbs
narrow _mp_alloc to INT_MIN. The problem is reproduced through mpz_init2,
mpz_realloc2 and mpz_limbs_modify with both GCC and Clang.

Proposed correction:
Reject allocation sizes greater than INT_MAX before writing _mp_alloc, both in
mpz_init2's direct allocation path and the shared mpz_realloc path.

Validation:
- AArch64 targeted boundary matrix: PASS.
- AArch64 upstream Mini-GMP test suite, original GCC: PASS.
- AArch64 upstream Mini-GMP test suite, patched GCC: PASS.
- AArch64 upstream Mini-GMP test suite, original Clang: PASS.
- AArch64 upstream Mini-GMP test suite, patched Clang: PASS.
- AArch64 regression comparison: PASS.
- x86_64 targeted INT_MAX / INT_MAX+1 matrix, GCC: PASS.
- x86_64 targeted INT_MAX / INT_MAX+1 matrix, Clang: PASS.
- x86_64 full Mini-GMP suite: NOT RUN in the submitted evidence package.

Scope limitation:
The evidence establishes the issue on the tested AArch64 and x86_64 LP64
systems. The full upstream suite was run on AArch64; x86_64 evidence is
currently targeted only. No claim is made for every ABI or upstream revision.
