Operation::Result#has_cursor_id? is defined as:

def has_cursor_id?
  acknowledged? && replies.last.respond_to?(:cursor_id)
end

For all OP_MSG operations replies.last is a Protocol::Msg, which does not define cursor_id (only the legacy Protocol::Reply does). So has_cursor_id? is always false on modern servers. Verified empirically against a live replica set: a find result with an open cursor (non-zero cursor_id) returns has_cursor_id? == false.

Affected code paths:

• lib/mongo/operation/shared/executable.rb (~line 67): the load-balanced cursor pin/unpin block (connection.pin / connection.unpin based on result.cursor_id) never executes. Since RUBY-3616 load-balanced cursors own their connection via explicit checkout, so the practical impact may be limited, but the dead code is misleading (it was the basis of an incorrect Copilot review finding on PR #3055) and the :cursor pin reason is effectively never set.
• lib/mongo/tracing/open_telemetry/command_tracer.rb (~line 209): the OpenTelemetry cursor id attribute is gated on has_cursor_id? && cursor_id.positive?, so it is never recorded.

Either fix has_cursor_id? to detect cursor responses in OP_MSG replies (e.g. delegate to the result classes that already parse the cursor subdocument), or remove the dead pinning block and has_cursor_id? if pinning is fully superseded by explicit connection ownership. Audit other pinned? checks (Cursor#check_in_connection, pool ensure blocks) when deciding.

Found while analyzing review remarks on PR #3055 (RUBY-3213).