Problem

The deferred multikey path can register multikey metadata without a concrete timestamp when the timestamp is not available at discovery time. The current fallback in mergeAndSortWorkerMultikeyPathInfo uses the batch's first timestamp before calling StorageInterfaceImpl::setIndexIsMultikey. This preserves the old conservative behavior but does not guarantee exact primary/secondary timestamp consistency for transaction cases where the actual commit timestamp is discovered later.

Scope

• Track the actual transaction commit timestamp for deferred multikey entries that are initially registered without a timestamp.
• Use that commit timestamp before flushing through StorageInterfaceImpl::setIndexIsMultikey.
• Preserve the strict non-null timestamp contract at StorageInterfaceImpl::setIndexIsMultikey.

Notes

The existing fallback is intentionally marked in the code as temporary. It should be replaced with exact commit timestamp handling so timestamp-consistent multikey metadata is maintained for prepared or transaction-owned null-timestamp cases.