[common] Reject out-of-range range-bitmap chunk-size option

[LuciferYang]

Purpose

close #9764

(int) MemorySize.parse(chunkSize).getBytes() narrowed the chunk-size option to an int, and what the narrowing produces depends on the value:

chunk-size	narrows to	result
2g	-2147483648	crashes on the writer's first ByteBuffer.allocate
4g, 8g	0	no failure at all: every key gets its own chunk and the index is silently bloated
5g	1g	no failure at all: silently builds the index at a quarter of the requested size

The crashing case is the one you notice. The other two are the reason to validate, because they produce a working-looking index from a configuration that was never honoured. The chunk size becomes an eagerly allocated per-chunk buffer, so nothing above int range can work in the first place.

This PR rejects anything above Integer.MAX_VALUE at writer creation with a message naming the option and the offending value. chunk-size is read as a free-form string with no typed ConfigOption, and MemorySize.parseBytes rejects a negative or overflowing value itself, so the accepted set after this guard is exactly [0, Integer.MAX_VALUE], which is exactly the set that narrows to itself.

Tests

RangeBitmapFileIndexTest#testChunkSizeBeyondIntRangeRejected pins the boundary rather than a sample either side of it: 2147483648 bytes is rejected with a message containing chunk-size, 2147483647 bytes is accepted, and 16mb still writes and serializes. 2g and 4g were dropped from it because they reach the guard through the same comparison as 2147483648 bytes, and their narrowing consequences cannot be asserted once the guard prevents them.

Verified on JDK 11 by mutating the comparison rather than reasoning about it. 18 tests pass as they stand. With the guard removed the test fails with Expecting code to raise a throwable, which also shows that on master createWriter() returns normally and the damage happens later during the write. With > changed to >= it fails on the accepted case with The 'chunk-size' option must not exceed 2147483647 bytes, but was '2147483647 bytes'.

API and Format

A new validation on an existing user option. Values that previously worked are unaffected; values above 2GB either crashed mid-write or silently built an index that ignored the setting.

Documentation

None needed. The behaviour on out-of-range values was a crash or silent misconfiguration, not a documented feature.