Evaluate std::optional for Token row identifiers and kInvalidRowId consistency

[coderabbitai]

Summary

Evaluate whether Token should represent its optional row identifier with std::optional<std::uint64_t>.

This follow-up is intentionally out of scope for PR #830.

Required evaluation

• Evaluate replacing Token::m_id and Token::m_hasId with std::optional<std::uint64_t>.
• Evaluate the related public API change. This includes whether to replace the id() and hasId() accessor pair with an optional-returning accessor.
• Evaluate whether form/storage/istorage.hpp should stop using the write-chain sentinel kInvalidRowId in the same change.
• Keep the Token representation and the write-chain representation consistent. Document the selected contract.

Rationale

Reviewers requested discussion of the std::optional representation. The current design uses an explicit validity flag in Token and a sentinel in the write chain. A single follow-up should decide whether those representations remain separate or change together.

Affected areas

• form/core/token.hpp
• form/core/token.cpp
• form/storage/istorage.hpp
• Write implementations that return row identifiers
• Read and write call sites and tests for Token

Acceptance criteria

• The issue records a decision for the Token identifier representation.
• The issue records a decision for kInvalidRowId and explains how the write-chain and Token contracts remain consistent.
• If an implementation change is selected, the follow-up updates the API documentation and tests for identified and non-addressable rows.

References

• PR Form: Return a Token from registerWrite #830: Form: Return a Token from registerWrite #830
• Review thread: Form: Return a Token from registerWrite #830 (comment)
• Related std::optional discussion: Form: Return a Token from registerWrite #830 (comment)

Requested by @wwuoneway. This issue captures reviewer interest from the std::optional discussion.