epath.Path equality depends on pathlib flavour, so a local path never equals a gs:// derived one on Windows

On Windows two `epath.Path` objects that stringify identically compare unequal, because they get different `pathlib` flavours. Measured on Windows 11, CPython 3.13.13:

```python
type(epath.Path('.')) -> WindowsGPath
type(epath.Path('gs://bucket/x')) -> PosixGPath

str(a) == str(b) -> True
a == b -> False
```

URI prefixes are registered to `PosixGPath` (`gpath.py:297-301`) while a bare local path takes the OS-native class, and `PurePath.__eq__` requires matching flavour.

Your own note in `rename()` already names this (`gpath.py:269-271`): `GPath.__new__` should pick the class dynamically, as `pathlib.Path` does. That is a redesign rather than a small fix, which is why I am filing instead of sending a patch.

It surfaces as `gpath_test.py::test_relative_to` failing here. `ubuntu-latest` cannot see it, because local paths there are Posix-flavoured too.

For a caller: comparing a path against a `gs://` one, or mixing both kinds as dict keys, silently behaves differently by platform.

No Linux on this machine, so the POSIX half is read from the registration logic rather than measured.

Start in gpath.py:269-271 and the URI registration at gpath.py:297-301, then inspect how GPath.__new__ and pathlib flavours select classes. Reproduce the Windows case from the issue and run gpath_test.py::test_relative_to. Done means local and gs:// paths with identical strings compare consistently, including when used as dictionary keys, without breaking POSIX behaviour.

Written by the indexing model from the issue text.