The RootedFileSystemProvider.resolveLocalPath() does not return normilized path any more

### Version

2.10.0

### Bug description

In the previous `2.9.2` version the `RootedFileSystemProvider.resolveLocalPath()` returns a normalized resolved path:
```
Path resolved = root.resolve(subPath);
resolved = resolved.normalize();
resolved = resolved.toAbsolutePath();
if (log.isTraceEnabled()) {
log.trace("resolveLocalPath({}): {}", absPath, resolved);
}

/*
* This can happen for Windows since we represent its paths as /C:/some/path, so substring(1) yields
* C:/some/path - which is resolved as an absolute path (which we don't want).
*/
if (!resolved.startsWith(root)) {
throw new InvalidPathException(r, "Not under root");
}
return resolved;
```

But in the current `2.10.0` it is like this:
```
Path resolved = IoUtils.chroot(root, path);

/*
* This can happen for Windows since we represent its paths as /C:/some/path, so substring(1) yields
* C:/some/path - which is resolved as an absolute path (which we don't want).
*
* This also is a security assertion to protect against unknown attempts to break out of the chroot jail
*/
if (!resolved.normalize().startsWith(root)) {
throw new InvalidPathException(root.toString(), "Not under root");
}
return resolved;
```

### Actual behavior

It even works well on Windows: looks it is forgiving for the trailing `.`.
On Linux we fails with error like this:
```
2023-07-11 14:26:23,978 DEBUG [sshd-SftpSubsystem-36168-thread-1] [org.apache.sshd.sftp.server.SftpSubsystem] - process(ServerSessionImpl[foo@/127.0.0.1:44840])[length=19, type=SSH_FXP_MKDIR, id=106] processing
2023-07-11 14:26:23,979 TRACE [sshd-SftpSubsystem-36168-thread-1] [org.apache.sshd.common.file.root.RootedFileSystem] - getPath(/foo/., []): /foo/.
2023-07-11 14:26:23,979 TRACE [sshd-SftpSubsystem-36168-thread-1] [org.apache.sshd.sftp.server.SftpSubsystem] - resolveFile(ServerSessionImpl[foo@/127.0.0.1:44840]) /foo/ => /foo/.
2023-07-11 14:26:23,979 DEBUG [sshd-SftpSubsystem-36168-thread-1] [org.apache.sshd.sftp.server.SftpSubsystem] - doMakeDirectory(ServerSessionImpl[foo@/127.0.0.1:44840])[id=106] SSH_FXP_MKDIR (path=/foo/[/foo/.], attrs={})
2023-07-11 14:26:23,979 TRACE [sshd-SftpSubsystem-36168-thread-1] [org.apache.sshd.common.file.root.RootedFileSystemProvider] - readAttributes(/foo/.)[/tmp/junit1261919202368611685/source/foo/.] type=BasicFileAttributes
2023-07-11 14:26:23,980 DEBUG [sshd-SftpSubsystem-36168-thread-1] [org.apache.sshd.sftp.server.SftpSubsystem] - doSendStatus[ServerSessionImpl[foo@/127.0.0.1:44840]][id=106,cmd=14] exception
java.nio.file.NoSuchFileException: /foo
at org.apache.sshd.common.file.root.RootedFileSystemProvider.translateIoException(RootedFileSystemProvider.java:585) ~[sshd-common-2.10.0.jar:2.10.0]
at org.apache.sshd.common.file.root.RootedFileSystemProvider.createDirectory(RootedFileSystemProvider.java:249) ~[sshd-common-2.10.0.jar:2.10.0]
at java.nio.file.Files.createDirectory(Files.java:700) ~[?:?]
at org.apache.sshd.sftp.server.SftpFileSystemAccessor.createDirectory(SftpFileSystemAccessor.java:487) ~[sshd-sftp-2.10.0.jar:2.10.0]
at org.apache.sshd.sftp.server.AbstractSftpSubsystemHelper.doMakeDirectory(AbstractSftpSubsystemHelper.java:1681) [sshd-sftp-2.10.0.jar:2.10.0]
at org.apache.sshd.sftp.server.AbstractSftpSubsystemHelper.doMakeDirectory(AbstractSftpSubsystemHelper.java:1632) [sshd-sftp-2.10.0.jar:2.10.0]
at org.apache.sshd.sftp.server.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386) [sshd-sftp-2.10.0.jar:2.10.0]
at org.apache.sshd.sftp.server.SftpSubsystem.doProcess(SftpSubsystem.java:327) [sshd-sftp-2.10.0.jar:2.10.0]
at org.apache.sshd.sftp.server.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:344) [sshd-sftp-2.10.0.jar:2.10.0]
at org.apache.sshd.sftp.server.SftpSubsystem.run(SftpSubsystem.java:303) [sshd-sftp-2.10.0.jar:2.10.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
```

### Expected behavior

Of course no error and restored behavior like in previous version.
In my project I have a workaround like this: https://github.com/spring-projects/spring-integration/pull/8676

### Relevant log output

_No response_

### Other information

_No response_