Error when putting file with permissions while ChrootDirectory is set

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

When I put -p somefile while the connected user has a ChrootDirectory set, the operation always fails with "remote fsetstat: Bad message".

The probable root cause was tracked down by @MichaelEischer. Quoting from https://github.com/restic/restic/issues/4335#issuecomment-2241315352:

The error looks very much like a bug in the homegrown chroot implementation used in the Windows openssh sftp port. In https://github.com/PowerShell/openssh-portable/blob/661803c9ec4d7dee6574eb6ff0c85b2b7006edb1/contrib/win32/win32compat/w32fd.c#L1013 it first retrieves the filepath for the handle (the real path on the windows filesystem) and passes it to w32_chmod which applies the chroot a second time!
That ultimately results in a call to _wchmod with a broken file path. This triggers an EINVAL error that gets translated to the "Bad message" error.

Expected behavior

sftp> put -p somefile
Uploading somefile to /somefile
somefile                                      100%   22KB   6.9MB/s   00:00
<transfer completes w/o error>

Actual behavior

sftp> put -p somefile
Uploading somefile to /somefile
somefile                                      100%   22KB   6.9MB/s   00:00
remote fsetstat: Bad message

Error details

No response

Environment data

AllowGroups ssh-backup
Match Group ssh-backup
	AuthorizedKeysFile C:/_backups/%u.authorized_keys
	ChrootDirectory C:/_backups/%u

Version

OpenSSH_for_Windows_9.4p1, LibreSSL 3.7.3

Visuals

No response

Reproduce the put -p failure with ChrootDirectory enabled, then inspect the referenced w32fd.c code around w32_chmod and its _wchmod path handling. Done means the transfer completes without the remote fsetstat: Bad message error when permissions are applied.