This suite runs the RunDBCheckInBackground hook. The hook runs the dbCheck command which generates {op: "c"} oplog entries as follows:

{ oplogEntry: { op: \"c\", ns: \"test0_fsmdb0.fsmcoll0\", ui: UUID(\"07b07822-7c51-410d-85e2-c5d5d4060998\"), o: { dbCheck: \"test0_fsmdb0.fsmcoll0\", type: \"batch\", md5: \"d381a905564387e42a68127855fecdf6\", minKey: MinKey, maxKey: MaxKey, readTimestamp: Timestamp(1651051063, 135), applyOps: null }, ts: Timestamp(1651051063, 156), t: 1, v: 2, wall: new Date(1651051063854), _id: { clusterTime: Timestamp(1651051063, 156), ts: Timestamp(1651051063, 156) } } }"}

Resharding doesn't ignore dbCheck oplog entries but it expects every {op: "c"} oplog entry to be an applyOps oplog entry or commitTransaction oplog entry or abortTransaction oplog entry. So upon seeing a dbCheck oplog entry, the ReshardingRecipientService would throw OplogOperationUnsupported here, and that would cause the resharding operation to fail/hang. dbCheck is a read-only operation so resharding should ignore dbCheck oplog entries. There is already a ticket for addressing this (SERVER-63855). Once that ticket is complete, we should be able to enable the internal_transactions_resharding.js run in that suite.