OperationContext contains a mutable ServerDeprioritization instance. When an operation like find deprioritizes a server due to a failure, that state persists in the OperationContext. If the same OperationContext is reused for a subsequent operation (e.g., change stream resume), the new operation inherits stale deprioritization state it should not have.

  Why this matters:
  1. Operations appear independent but share hidden mutable state.
  2. Code treats OperationContext as immutable (e.g., ClusterFixture uses it as a constant)
  3. Easier to introduce similar issues as more operation start reusing OperationContext.

  Current impact (relatively low):

• Change streams: Resume attempts inherit deprioritization from prior find operations.
• Tests using shared OperationContext from ClusterFixture have cross-test contamination.

Suggested change:

1.  Create ServerDeprioritization in retry scope, for example in retry helpers (executeRetryableRead, executeRetryableWrite) - so that deprioritization state is scoped to each retry loop and server selection, not shared beyond retry boundaries
2.  Pass ServerDeprioritization to server selection via operationContext.withServerDeprioritization() - to bound deprioritization only to server selection.
3. Pass OperationContext with empty ServerDeprioritization to ExecutionFunction (responsible for executing command).

Additional consideration for long-term maintability (should be a separate ticket): 
Discussed with valentin.kovalenko@mongodb.com Introduce immutable scoped context objects:

• ServerSelectionContext - to make server selection boundaries explicit in the type system, so server-selection-specific data (like ServerDeprioritization) cannot accidentally leak to other phase.
• CommandContext - to use command-specific data per command being executed instead of global operation context. Relationship is many to one: CommandContext's related to one OperationContext.