## Description: 
During an SMB2 rename, the server internally re-opens the destination parent
directory with a fixed `DesiredAccess = FILE_ADD_FILE | SYNCHRONIZE` and a
fixed `ShareAccess`. Per [MS-FSA] 2.1.5.15.12 `FileRenameInformation`
(product-behavior footnote `<185>`), that internal open's `ShareAccess` does
not include `FILE_SHARE_DELETE` on Windows Server versions up to and
including Windows Server 2022. Samba 4.23.5 correctly implements this same
"no `FILE_SHARE_DELETE`" semantics (this was a deliberate fix vs. 4.20.6,
which had an incomplete, process-local-only conflict check and is not the
subject of this request).

Beginning with Windows Server 2025/2026, Microsoft added `FILE_SHARE_DELETE`
to that same internal open's `ShareAccess`. As a result, on Windows Server
2025/2026 a rename into a destination directory that is already open
elsewhere with `DELETE` access (but otherwise compatible sharing) now
succeeds, where it would previously (and still on Samba 4.23.5) fail with
`STATUS_SHARING_VIOLATION`.

## Current Samba behavior (observed)
smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_SHARING_VIOLATION] || at smb2_setinfo.c:142

#Trigger pattern:
CREATE  -> opens source file with full access incl. DELETE, share_access=0x7
SETINFO -> rename to target dir -> FAILS: STATUS_SHARING_VIOLATION

where a separate handle already has the destination directory itself open
with `DELETE` access (e.g. via `open_directory`, access_mask including
`SEC_STD_DELETE` / `FILE_SHARE_DELETE` not granted to the new internal open).

## Request
Consider adding `FILE_SHARE_DELETE` to the `ShareAccess` used by the internal
destination-parent-directory open performed during `FileRenameInformation`
processing (`smbd_smb2_setinfo_rename_dst_parent_check()` / the internal
re-open path in `smb2_setinfo.c`), gated appropriately (e.g. behind a
version-compatibility check or config knob) so that Samba can optionally
track the newer Windows Server 2025/2026 semantics rather than only the
Windows Server ≤2022 semantics.