Windows drive-path heuristic can bypass leading-slash normalization

The function is small and has no direct memory-safety issues:

- `src[1]` is only accessed when `len(src) > 2`.
- `src[0]` is only accessed when `len(src) != 0` due to Go short-circuit evaluation.
- `dst` is handled with `append`, so no fixed-size buffer overflow is possible inside this function.
- There is no integer arithmetic, no unsafe pointer use, no goroutine, no error return, and no fallible operation.

The only security-relevant concern is a path-normalization weakness. `isDisk` is computed as:

```go
isDisk := len(src) > 2 && src[1] == ':'
```

This treats any path whose second byte is `:` as a Windows disk path, without validating that the first byte is actually a drive letter. An attacker-controlled URI/path value such as `1:2`, `a:..`, or `x:evil` can therefore avoid receiving a leading `/`. If downstream code assumes the returned path is root-relative, uses the presence of a leading slash for traversal checks, or appends the path after an authority component, this incomplete normalization could lead to malformed URIs or potential path-handling bugs. The impact is caller-dependent and does not constitute a memory-corruption bug in this function itself.

```json
[
  {
    "severity": "low",
    "title": "Windows drive-path heuristic can bypass leading-slash normalization",
    "function": "addLeadingSlash",
    "description": "isDisk is computed as len(src) > 2 && src[1] == ':' without checking that src[0] is a valid drive letter. Attacker-controlled URI paths such as '1:2' or 'a:..' are therefore treated as disk paths and do not receive a leading '/'. If downstream URI or path handling assumes a root-relative path, uses the leading slash for traversal/normalization checks, or appends the path after an authority component, this incomplete normalization may be exploitable. The function itself does not have a direct memory-safety defect."
  }
]
```