Ensure RNTuple write/commit crash consistency before registering Tokens

[coderabbitai]

Summary

ROOT_RField_Write_ContainerImp::fill() returns the 0-based index of a pending RNTuple entry. The entry is not persisted until ROOT_RField_Write_ContainerImp::commit() calls RNTupleWriter::Fill().

If an exception stops the write sequence after fill() and before commit(), a Token created from that row index can refer to a row that was never persisted.

Required changes

In the follow-up that starts collecting Tokens and passes them to commitOutput():

• Do not register or publish a Token for an RNTuple entry until that entry has committed successfully.
• Define the failure behavior when fill() succeeds but commit() fails.
• Add tests for the successful commit path and for failures between fill() and commit().

Affected area

• form/root_storage/root_rfield_write_container.cpp
• The follow-up Token collection and commitOutput() flow

Acceptance criteria

• A Token exposed to downstream code always refers to a persisted RNTuple row.
• A failed or interrupted commit does not leave a registered Token for an unwritten row.
• Tests cover the required behavior.

Backlinks

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

[aolivier23]

Is this an RNTuple problem or a storage/persistence/interface problem? I want to jump in and help if it's an RNTuple problem. However, I can imagine how we might have storage_write_container::commit() return a token instead of storage_write_container::fill(). Then we'd move up FORM's hierarchy and persist the token when persistence_writer::commit_output() is called.

What do you think? Is there something I can do with RNTuple now to help?