As seen in BF-35793.

1. Router targets a shard with a specific atClusterTime within a transaction
2. The shard acts as an embedded router for the transaction and stores the atClusterTime in its router state
3. The shard adds participants to the transaction and adds to the participant list in its router state
4. The transaction ends up failing and the top level router retries and targets the shard again with a new atClusterTime
5. The shard does not reset its router state since its participant list is not empty. We tassert because the new atClusterTime does not equal the old atClusterTime that is stored in the shard's router state

We should update how transaction retries are handled in this specific scenario so that we do not hit this tassert.