Revisit RNTuple write-token row IDs when adopting RNTupleParallelWriter

[coderabbitai]

Summary

ROOT_RField_Write_ContainerImp::fill() currently derives the pending row ID from ROOT::RNTupleWriter::GetNEntries().

This is correct for the current single-threaded ROOT::RNTupleWriter implementation. FORM uses one shared RRawPtrWriteEntry and performs one Fill() for each commit().

Required follow-up

If FORM adopts ROOT::RNTupleParallelWriter, redesign the row-ID computation that produces the returned Token ID.

Each parallel writer thread uses an independent RNTupleFillContext. Final row indices are assigned only during cluster flush or merge. Therefore, GetNEntries() cannot identify the final row for a pending write and can produce incorrect or racy Token IDs.

Affected area

• form/root_storage/root_rfield_write_container.cpp
• ROOT_RField_Write_ContainerImp::fill()
• Write-token row-ID propagation through storage and persistence writers

Acceptance criteria

• Parallel RNTuple writes return a Token ID only when the final global row index is known.
• The implementation does not derive a final row ID from a per-thread pending entry count.
• Tests cover row-ID correctness for the selected parallel-writing design.
• The API documents any case where a Token has no row ID.

References

• Pull request: Form: Return a Token from registerWrite #830
• Review thread: Form: Return a Token from registerWrite #830 (comment)

Requested by: @wwuoneway