should any/all of the following tests keep ownership with query or switch to an appropriate CAR team.

jstests/concurrency/fsm_workloads/random_moveChunk/random_moveChunk_constraint_validation.js (SERVER-123715)
FSM concurrency workload that exercises prepareConstraintValidationLevel and upgradeToConstraint racing with concurrent chunk migrations. Threads cycle through writing valid/invalid docs, preparing, upgrading, and downgrading between strict and constraint levels while the balancer moves chunks in parallel. Validates that scan failures (non-conforming docs) are handled correctly and invalid docs are cleaned up.

jstests/noPassthroughWithMongod/query/prepare_constraint_validation_level_failpoint.js (SERVER-123713)
Tests that a bypassDocumentValidation write already holding the collection IX lock is not starved or killed when a collMod prepareConstraintValidationLevel arrives and waits for the X lock. Uses a failpoint to pause the write mid-flight and confirms both the write and the subsequent collMod succeed.

jstests/sharding/query/collmod_upgrade_to_constraint_sharded.js (SERVER-123711)
Tests the coordinator-driven non-compliant document scan for sharded collections. Verifies that upgrading validationLevel to constraint is blocked when a violating document exists on a non-coordinating shard, and is allowed once all documents conform across all shards.

jstests/noPassthrough/query/prepare_constraint_blocks_invalid_wcos_updates.js (SERVER-127372)
Tests that cross-shard updates moving a non-compliant document to a different shard are blocked while prepareConstraintValidationLevel is set. Covers both shard-key updates and non-shard-key _id-based updates, which MongoDB converts to delete-then-reinsert transactions — the reinsert goes through normal validation and fails.

jstests/sharding/query/collmod_constraint_scan_with_chunk_migration.js (SERVER-128100)
Two targeted scenarios for the constraint validation scan racing with chunk migrations: (1) a migrated invalid doc that moved after the scan cursor was established is still detected via range preservers on the donor; (2) a doc updated to become valid mid-scan is still flagged as a false positive from the orphan on the donor shard — then a retry proves it was transient.