The "backup" command in smbclient is documented to toggle the backup intent flag
sent to the server on directory listings and file opens. It appears to have no
effect - the flag never reaches the wire. Verified with packet captures on both
4.19.5 and a 4.22.0 build from source.

Environment:
- Client: Ubuntu 24.04 (Noble)
- Reproduced on smbclient 4.19.5-Ubuntu (2:4.19.5+dfsg-4ubuntu9.7) and on
  4.22.0 built from source (configure --prefix=/opt/samba422 --without-ad-dc
  --without-winbind --without-ldb-lmdb --without-pam
  --with-shared-modules='!vfs_snapper' --disable-cups)
- Server: Windows Server 2019 file server, SMB 3.1.1 negotiated
- Auth: NTLMv2 (no KDC reachable in this environment, falls back cleanly)
- Service account holds SeBackupPrivilege on the target server
- Target path is not in the account's NTFS ACL

Steps to reproduce:

1. Confirm the server-side privilege works, using the kernel CIFS client with
   the same account, server and path:

     mount -t cifs //server/share/Folder /mnt/test \
       -o credentials=/home/user/credentials,backupuid=0,rw

   Succeeds. Removing backupuid=0 makes the same mount fail with
   "mount error(13): Permission denied", which confirms backup intent is what
   makes it work rather than ordinary ACL access.

2. Attempt the equivalent with smbclient:

     smbclient //server/share -A /home/user/credentials -c 'backup; get Folder\Sub\test.txt'

   Result: NT_STATUS_ACCESS_DENIED opening remote file \Folder\Sub\test.txt

3. Packet captures of both, same account, same server IP, same path, same
   SMB 3.1.1 dialect.

   mount.cifs with backupuid=0, SMB2 CREATE requests:
     Create Options: 0x00004000
     Create Options: 0x00004000
     Create Options: 0x00004000
     Create Options: 0x00004000
     Create Options: 0x00004000
     Create Options: 0x00004001
     Create Options: 0x00004000

   smbclient with 'backup' toggled, SMB2 CREATE requests:
     Create Options: 0x00000001
     Create Options: 0x00000000
     Create Options: 0x00000040

   The 0x4000 (FILE_OPEN_FOR_BACKUP_INTENT) bit is set on every create from the
   kernel client and on none from smbclient. Identical output on 4.19.5 and
   4.22.0.

Also checked:
- Connecting directly to the file server instead of through the DFS namespace
  root - same result, so this is not DFS referral related.
- Debug level 10 shows map_open_params_to_ntcreate logging
  create_options = 0x40 for the file open.
- There is no -b / --use-backup-intent command line option in these builds;
  'backup' as an interactive or -c command is the only way to reach this, and
  that is what was used.

Expected: after toggling 'backup', subsequent opens should include
FILE_OPEN_FOR_BACKUP_INTENT in create_options.

Actual: the flag is never sent, and behaviour is identical with and without the
toggle.

Possible starting point: source3/client/client.c has a module-level
"static bool backup_intent", while cli_smb2_create_fnum_send() in
source3/libsmb/cli_smb2_fnum.c tests cli->backup_intent. If cmd_backup only
updates the static and it is not propagated onto the cli_state used for the
operation, that would produce exactly this behaviour. Note also that
operations here go through cli_resolve_path(), which can return a different
targetcli than the global cli.

Pcaps for both cases available. Happy to test patches.