The mocha subtest "optime initialized to cluster time with no start option" in jstests/change_streams/change_stream_metrics_currentop.js fails intermittently in the sharded_clusters_disagg_change_streams_per_shard_cursor_passthrough suite:

assert: Timestamp(1787548461, 6) is not greater than or eq Timestamp(1787548461, 9)
  : Expected changeStreams.optime greater or equal to the cluster time snapshot

Root cause

This is a test race. The test snapshots $clusterTime from an insert reply and then asserts that a freshly opened change stream (no start option) reports changeStreams.optime >= clusterTime in $currentOp.

On the config shard, background sharded DDL activity (drop coordinators, internal 2PC transactions, checkMetadataConsistency) advances the gossiped logical clock past the visible oplog tip. A change stream opened with no start option derives its initial optime from the oplog tip / initial postBatchResumeToken, so the reported optime ((...461, 6)) can lag the gossiped cluster time snapshot ((...461, 9)), failing the assert.gte. The window is wider in disagg suites due to log-server visibility lag, which is what the pre-existing TODO SERVER-128391 comment in the test was observing.