internal/cloudstorage: handle Windows volume paths

[arpitjain099]

Summary

internal/cloudstorage.parseBucketAndPrefix passes the raw destination to url.Parse. On a Windows absolute path like C:\path\to\file, url.Parse reads the drive letter as a single-character URL scheme (c), and url.URL.IsAbs() then returns true. That skips the scheme-less local-file branch entirely, so the volume is never recognised as a filesystem path and path.Split operates on the wrong value.

This is what makes the cmd/enumerate_github/marker tests fail on Windows, where t.TempDir() hands back volume-rooted absolute paths (#337).

Reproduction

url.Parse on a volume path:

url.Parse(`C:\foo\bar`)  -> scheme="c", opaque="\foo\bar", IsAbs()=true
url.Parse(`c:/foo/bar`)  -> scheme="c", path="/foo/bar",   IsAbs()=true

Because IsAbs() is true, the value is treated as a cloud bucket with scheme c instead of a local file.

Fix

Detect a single-letter drive followed by a volume separator (hasWindowsVolume) before parsing. When present, build the URL as an absolute local filesystem path, normalising backslashes to forward slashes so path.Split behaves the same regardless of the host OS, and prefixing / so the volume stays in the URL path rather than being parsed as a host.

Real scheme URLs (gs://, s3://, file://, mem://) take the existing url.Parse path and are unchanged.

Before / after

For C:\path\to\file:

• before: scheme c, bucket mis-parsed, prefix wrong.
• after: bucket file:///C:/path/to/?metadata=skip, prefix file. This mirrors the existing handling of a POSIX absolute path like /path/to/file (bucket file:///path/to/?metadata=skip, prefix file).

Tests

Added a table-driven TestParseBucketAndPrefixWindowsVolume covering the backslash, forward-slash, and lowercase-drive-letter forms. The case fails on the current source (drive letter parsed as scheme) and passes with the fix. The existing local-path and scheme-URL tests continue to pass.

go test ./internal/cloudstorage/ is green and go build ./... succeeds. These tests run on any OS, so they guard the Windows behaviour from a Linux CI runner.

Closes #337