Overview

SlotBinder::Kind::kClusteredRecordIdPair in SbeSingleDocumentLookupExecutor and the isClusteredOnId branch in ExpressSingleDocumentLookupExecutor both implement dedicated clustered-collection logic for change stream updateLookup, but no existing test explicitly creates a clustered collection and exercises this path – for either engine, for scalar or compound _id, or for the collation-driven decline-to-fallback case (a non-simple collation on a clustered key makes SBE's SlotBinder::make decline).

Scope of Work

• Extending jstests/change_streams/change_stream_metrics_update_lookup.js with a clustered-collection dimension (scalar + compound _id) and a collation-fallback case, plus asserting on actual fullDocument content (previously only metric counts were checked).
• Extending jstests/sharding/query/change_streams/change_stream_metrics_update_lookup.js with a clustered-collection shard-key config, reusing the existing relocation scenarios.
• Adding matching clustered-collection unit test coverage to express_single_document_lookup_executor_test.cpp (the SBE executor's test file already had this; the Express one didn't).
• Fixing a pre-existing flaky-test bug uncovered while verifying the above: the sharded test's hashed _id shard-key config assumed numInitialChunks: 1 pins the test document to shard0. It doesn't – SplitPointsBasedSplitPolicy::createFirstChunks (initial_split_policy.cpp) ignores numInitialChunks for hashed shard keys entirely and always creates one chunk per shard, with shard assignment shuffled at creation time (getAllNonDrainingShardIdsShuffled). So the document could start on either shard by chance, making the "primary observes it locally, then declines after relocation" scenario non-deterministic. This is a test bug, not a product bug – updateLookup always returned the correct document. Fixed by explicitly normalizing placement to shard0 after insertion, before each scenario's relocation step.