GHSA-c9cv-mq2m-ppp3

### Summary Three weaknesses in Nuxt's client-navigation URL handling, all reachable from documented public APIs (`navigateTo` and `reloadNuxtApp`): 1. **SSR open redirect in `navigateTo` via path-normalisation bypass.** `navigateTo` decided whether a target was external by inspecting the raw input with `hasProtocol(..., { acceptRelative: true })`. Inputs such as `/..//evil.com`, `/.//evil.com`, `/%2e%2e//evil.com`, or `/app/..//evil.com` slipped past that check because they start with `/`, but WHATWG URL parsing then normalised them to the protocol-relative pathname `//evil.com`. The normalised value was written to the `Location` response header and into the `<meta http-equiv="refresh">` body of the SSR redirect page, so a victim's browser would resolve the redirect cross-origin to the attacker's host. 2. **Client-side script execution via `navigateTo({ open: ... })`.** The client-side early-open handler called `window.open(toPath, ...)` without applying the `isScriptProtocol` check that gates the normal `navigateTo` path. A target of `javascript:...` (or another script-capable scheme) passed to `navigateTo(url, { open: { ... } })` therefore executed in the application's origin instead of being rejected. 3. **Open redirect in `reloadNuxtApp` via protocol-relative bypass.** `reloadNuxtApp({ path })` rejects script-capable protocols by parsing the path with `new URL(path, window.location.href)` and checking the resolved `protocol` against `isScriptProtocol`. Protocol-relative paths such as `//evil.com` resolve to the current page's protocol (`https:`), which passes that check; the value is then assigned to `window.location.href`, which the browser treats as a cross-origin redirect. This is the same protocol-relative bypass family as (1), in a different sink. ### Impact For (1), the practical risk is phishing or OAuth-code theft against any Nuxt app that forwards user-controlled input (for exam