As part of the client backpressure work (JAVA-6238), overload retry lifecycle handling spans both SpecRetryPolicy and session-related state. 

This ticket proposes moving the session-specific pieces behind SessionContext notification methods, so SpecRetryPolicy can work with a smaller surface area. This should educe the amount of session-specific detail needed outside the session layer.

Proposed change:

• Replace direct exposure of overload retry internals from SessionContext with flat lifecycle notification methods, for example:
  • notifyCommandExecutionStarted()
  • notifyCommandExecutionEnded()
  • notifyAttemptFailed(boolean retryableOverloadError)
• observedNoneOrOnlyRetryableOverloadErrors is currently duplicated rather than reused from the DefaultCommandExecutionScoped. Reusing the existing field would require exposing another getter from session internals, which goes against the notification-method direction proposed in this ticket. As part of this refactoring, we should revisit what to do with this state. Ideally, SpecRetryPolicy should track retry-policy state and notify the session that it observed a retryable overload error, while the session should own the decision to mark that startTransaction is no longer needed. See related discussion: https://github.com/mongodb/mongo-java-driver/pull/2041#discussion_r3833989334

SessionContext should own routing to command/commit scoped state internally. SpecRetryPolicy should depend only on SessionContext, not on session-internal classes.

See: https://github.com/mongodb/mongo-java-driver/pull/2041#discussion_r3833989334