In BF-35775, backup cursors were killed too early, leading FCBIS to fail. max.hirschhorn@mongodb.com suggested that they could be associated with a session so that they would be subject to localLogicalSessionTimeoutMinutes instead of cursorTimeoutMillis, which would also keep them alive as long as the syncing node was using them. His full comment:

> However it isn't clear to me why the cursor timeout is being applied to a backup cursor. My understanding of their intended usage is that they are meant to leverage a logical session to extend their lifetime. Cursors which are created under a logical session don't follow cursorTimeoutMillis and instead rely on logical session expiry (localLogicalSessionTimeoutMinutes == 30 minutes) and the expiry can be deferred as long as the logical session is in use on some cluster node (i.e. the syncing node). Would using a logical session be a server change we'd potentially want to make to the syncing node for how it runs its operations as part of file-copy based initial sync? I can understand if not because we've only seen this problem in testing and the production default of 10 minutes is pretty long already.

This ticket has 2 parts: (1) decide whether or not this is something we want to do, and (2), do (or schedule) the work.