Constant-time AES-GCM bulk batching, mode-wide in-place AEAD correctness

[Xor-el]

Constant-time AES-GCM bulk batching, mode-wide in-place AEAD correctness, and non-lagged fused decrypt

Bulk batching (constant-time software AES-GCM):

• TAesBitSlicedEngine implements IBulkBlockCipher, transforming four blocks per pass (the aes_ct64 lane width) with a 1..3-block tail; bit-exact with N sequential ProcessBlock calls. SIC/CTR over it now batches automatically.
• GCM gains a software-bulk 4-block path (bulk AES keystream + scalar GHASH) gated on the engine being bulk-capable rather than on SIMD GHASH, so the bitsliced + software-multiplier stack batches even without hardware GHASH.
• Scalar aggregated 4-way GHASH: split the field multiply into MultiplyNoReduce + ReduceProduct and fold four blocks with a single reduction (reduction is XOR-linear); H^1..H^4 precomputed per key.
• TGcmBlockCipher gains a destructor and zeroizes the hash subkey, H-power tables, keystream buffers and last key on teardown/rekey.

In-place AEAD correctness (out buffer aliasing in buffer):

• In-place GCM was broken mode-wide in both directions. Fixed uniformly: CipherBlock/CipherBlocks2 use the three-operand XOR (read both sources before writing), and every block step orders GHASH so decrypt folds the input before the XOR overwrites it and encrypt folds the output after.
• EAX (the only other affected mode) captures each block's ciphertext into the OMAC look-ahead before the in-place counter transform overwrites it.
• The other block-cipher modes were reviewed and are already in-place safe.

Non-lagged fused decrypt (x86_64, i386, aarch64):

• The fused CTR + 8-way GHASH kernel lagged GHASH by one batch, so in-place decrypt read overwritten memory. Encrypt still lags (its ciphertext is the output); decrypt now GHASHes each batch's own input during that batch's AES rounds, before the XOR, with identical instruction-level parallelism and no prime/drain. In-place GCM decrypt now runs at full fused speed on all three architectures with no aliasing fallback.

Also: TAesBitSlicedEngine.ProcessBlocks (pointer form) computes its byte count in Int64 to avoid a 32-bit overflow on very large block counts.

Tests: in-place round-trip coverage (both directions, sizes crossing the fused thresholds, cipher-kernel on/off) added to the GCM, EAX and bitsliced suites; ProcessBlocks parity, CTR batched-vs-single, aggregated-GHASH parity, and chunked-stream parity.