(New issue branching off discussion on #56336.)

https://go.dev/cl/444280 changed Windows volume name detection to be more accurate, correctly detecting a number of previously unrecognized volume name prefixes such as \\.\?\UNC\a\b. (Yes, that's a valid volume name.)

This change also results in us treating some invalid filenames as containing a prefix. For example, \\ is not a valid Windows filename, but we now consider it to have a \\ volume name on the grounds that preserving the semantically-significant \\ prefix is better than ignoring it.

A consequence of this change is that on Windows filepath.Clean can produce a path that can contain .. elements. For example, filepath.Clean("//../../a") is \\..\..\a. I'm not sure if \\..\.. is a valid Windows volume name or not, but a consequence of this is that code like

// Incorrect: Please do not write this.
path = filepath.Join(root, filepath.Clean("/" + slashSeparatedPath))

can produce a result that escapes the intended root when slashSeparatedPath is something like /../../foo.

While this code should be written as something like

// Using path.Clean rather than filepath.Clean avoids applying Windows volume semantics to the input path.
path = filepath.Join(root, path.Clean("/" + slashSeparatedPath))

we can still do a better job of defending against vulnerabilities caused by this misuse of filepath.Clean by rejecting volume names that contain .. as a component. So far as I know, .. never appears in Windows volume names.

Concretely:

filepath.Clean(`\\..\..\a`) = `\a`
filepath.VolumeName(`\\..\..\a`) = ``