[ntuple] Add RNTupleLocatorMulti class for kTypeMulti locator

[JasMehta08]

This Pull request:

(Is a part of the GSoC 2026 project S3 Backend for RNTuple.)

Changes or fixes:

Follow-up to #22434. Introduces a dedicated RNTupleLocatorMulti class for the kTypeMulti locator, replacing the previous reuse of RNTupleLocatorObject64.

The new class stores the object identifier and byte offset as two explicit 32-bit fields plus a separate 4-bit reserved field. GetLocation() returns the canonical packed 64-bit value (parallel to RNTupleLocatorObject64::GetLocation()), with the layout:

• bits 63..60: 4 reserved bits
• bits 59..30: 30-bit object identifier (max ~1 billion objects)
• bits 29..0: 30-bit byte offset (max 1 GiB per object)

The (uint32_t, uint32_t) constructor and SetReserved() validate their inputs against the 30-bit and 4-bit ranges respectively. The 0x03 payload remains a 4/8-byte size followed by an 8-byte packed value, so the wire format stays identical.

RNTupleLocator::SetPosition and GetPosition<> are split accordingly so RNTupleLocatorObject64 is now reserved for kTypeObject64 only, and the new RNTupleLocatorMulti overload/specialization handle kTypeMulti.

Checklist:

• tested changes locally
• updated the docs (if necessary)

This PR is a follow-up #22434

[jblomer]

Nice! Some simplification is possible, I think, by not storing reserved bits altogether.

[jblomer]

Thinking about it, we probably don't need to store the reserved bits because we anyway don't know what to do with them. That should also avoid the need for masks.

[jblomer]

Here, I think we should write the two integers (object id, offset) as 32bit integers to disk. This avoids any potential issues of platform-independence when we combine the two integers in a single 64 bit int.

[github-actions]

Test Results

    19 files      19 suites   3d 2h 44m 25s ⏱️
 3 863 tests  3 810 ✅ 0 💤 53 ❌
66 233 runs  66 168 ✅ 1 💤 64 ❌

For more details on these failures, see this check.

Results for commit 0d8ca56.