gel on Windows calculates path sha different than libraries

- Gel Version: 6.11+66a1377
- Gel CLI Version: 7.10.0-dev.1463+ff1bd8d
- OS Version: Windows 11

Steps to Reproduce:

1. Run `gel project init` in a project on Windows and the project will be initialized and a new `gel.toml` created, along with a corresponding `[project-name]-[path-hash]` directory in `C:\Users\USER\AppData\Local\EdgeDB\config\projects`.
2. Run any code using a gel library and the first database call will fail with a `project is not initialized` error.

Analysis:

The CLI, as of 482062b683b09085942f7999fac07fab6dbd6504, is using `dunce::canonicalize` to generate the project path, which returns a path something like `C:\Users\Zach\Dev\kaweah-tech\ff.app` which generates a hash of `be8268f00bfb7a7d249da0854ac91729624fdbf2`. The project code appends a prefix of `\\?\` to the path so it uses `\\?\C:\Users\Zach\Dev\kaweah-tech\ff.app` to generate a hash of `f660887260d84cf3ecb590335ddff78600bbbad1`. The end result is that the project code is looking for a config file `ff.app-f660887260d84cf3ecb590335ddff78600bbbad1` which doesn't exist because the CLI created the config at `ff.app-be8268f00bfb7a7d249da0854ac91729624fdbf2`.

I believe this is an issue with all the libraries based on [this search](https://github.com/search?q=org%3Ageldata+%5C%5C%5C%5C%5C%5C%5C%3F%5C%5C%5C%5C&type=code), so I suspect the fix needs to be made in the `gel-cli` project to reduce the amount of potential turbulence.

Start with the `gel project init` path-hash generation and the CLI use of `dunce::canonicalize`; compare it with the path normalization used by the project code. Reproduce the mismatch on Windows 11 and trace where the `\\?\` prefix is added. Done means the CLI and Gel libraries generate the same project configuration directory name and the initialization flow succeeds.

Written by the indexing model from the issue text.