`~` is a member of RFC 7235 §2.1 `token68`,
and thus of RFC 6750 §2.1 `b64token`,
but the allowlist stripped it,
silently corrupting any opaque Bearer credential containing it:
Bearer mF_9.B5f-4.1JqM~+/= -> Bearer mF_9.B5f-4.1JqM+/=
`Basic` credentials were never affected,
since RFC 4648 §4 base64 cannot emit `~`;
`;` stays stripped, as it belongs to no auth-scheme production.
Cover the charset in the unit test,
and assert the credential reaches the downloader intact via the existing fake-`wget` harness,
which needs no container.
`nvm_has` matches shell functions and aliases,
but downloads now run via `command`, which skips them
- a `curl` shell function with no curl binary on the PATH would select the curl path and fail with exit 127,
instead of falling back to an available wget executable.
The new `nvm_has_executable` helper resolves names the same way `command` does, so downloader selection and execution agree.
The wget path passed `NVM_AUTH_HEADER` as the raw header line
(e.g. `--header "Bearer secret-token"`),
omitting the `Authorization:` header name that the curl path includes.
Per the documented usage
(`NVM_AUTH_HEADER="Bearer secret-token"`) the value is the credential,
so wget was sending a malformed header.
Prefix it with `Authorization: ` to match the curl path.
Andres Mejia Sanchez
Jordan Harband