Problem

When a secondary applies a mixed oplog batch containing no-txn writes and prepared transaction writes against the same indexed collection, a transaction can locally rediscover a multikey path that the primary did not author as a transaction multikey transition.

The sequence is:

1. A no-txn regular insert creates a scalar document.
2. A no-txn multikey update makes the indexed path multikey on the primary.
3. A later prepared transaction writes an already-multikey value for the same path.
4. On the primary, the transaction does not emit setMultikeyMetadata, because the path is already multikey.
5. On the secondary, the no-txn multikey update is still pending in MultikeyPathTracker until batch-end flush, so the prepared transaction sees stale catalog state and records a new tracked multikey path with a null MultikeyPathInfo::earliestTimestamp.
6. The batch-end multikey flush falls back to the batch's first timestamp, making the secondary expose the path as multikey earlier than the primary.

Why this is wrong

With explicit transaction multikey replication enabled, transaction-authored multikey metadata should be represented by setMultikeyMetadata. If a prepared transaction does not emit that metadata, then the transaction was not the primary author of the multikey transition.

The secondary should not create a null-timestamp transaction entry through IndexCatalogEntryImpl::setMultikey in this case.