• Create PR with unit tests

Description

In the TS config reader, pnpm_config_auth.registries is merged into pnpmConfig.registries but
not into pnpmConfig.packageManagerRegistries, so package-manager bootstrap/self-download flows
(e.g. switchCliVersion) won’t honor JSON env scoped registries and may resolve against the wrong
registry or fail in CI.

Code

pnpm11/config/reader/src/index.ts[R485-495]

const workspaceRegistries = pnpmConfig.registries as Record<string, string> | undefined
pnpmConfig.registries = {
...registriesFromNpmrc,
...workspaceRegistries,
+    // Trusted env layer wins over the repo-controlled yaml on conflicting
+    // scope keys (mirrors the env-over-workspace ordering in loadNpmrcFiles.ts).
+    ...npmrcResult.envJsonAuth.registries,
+    // CLI per-scope registries re-applied last so an explicit
+    // `--@scope:registry=...` flag wins over yaml AND env JSON, matching
+    // the documented "CLI > env > yaml" precedence.
+    ...cliScopedRegistries,

Evidence

The code merges JSON env registries into pnpmConfig.registries, but packageManagerRegistries is
created earlier from trusted sources that do not include envJsonAuth.registries. Bootstrap flows
consume packageManagerRegistries via getPackageManagerBootstrapConfig, so they won’t see JSON
env scoped registries.

pnpm11/config/reader/src/index.ts[325-339]
pnpm11/config/reader/src/index.ts[466-513]
pnpm11/config/reader/src/loadNpmrcFiles.ts[135-177]
pnpm11/pnpm/src/packageManagerRegistries.ts[19-37]
pnpm11/pnpm/src/switchCliVersion.ts[31-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pnpm_config_auth.registries` is applied only to `pnpmConfig.registries`. However, pnpm’s package-manager bootstrap path (used for pnpm self-download/version switching) uses `config.packageManagerRegistries`, which is built from `trustedConfig` and does not include `envJsonAuth.registries`. This makes the new JSON env registry routing ineffective for bootstrap flows.
## Issue Context
- `envJsonAuth.registries` is intentionally kept out of `mergedConfig`/`trustedConfig` (it is merged later in `index.ts`).
- `packageManagerRegistries` is derived from `trustedAuthConfig`/`trustedNetworkConfigs`, so it will miss JSON env registries unless they are explicitly merged.
## Fix Focus Areas
- pnpm11/config/reader/src/index.ts[466-513]
### Concrete fix
After merging/normalizing `pnpmConfig.registries`, also merge `npmrcResult.envJsonAuth.registries` into `pnpmConfig.packageManagerRegistries` (normalize URLs), so bootstrap uses the same trusted env registry routing.
### Test
Add a config-reader test that sets `pnpm_config_auth={"registries":{"@pnpm":"https://mirror.example/"}}` and asserts `config.packageManagerRegistries['@pnpm']` (and/or bootstrap registries) reflects it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In pacquet, pnpm_config_auth.registries is removed from env_json_auth before building
PackageManagerBootstrap, and only re-inserted into Config.registries later, so bootstrap
registry routing can miss JSON-provided scope routes. This can cause pnpm auto-switch downloads
(bootstrap path) to resolve scoped packages against the wrong registry or fail entirely in
restricted environments.

Code

pacquet/crates/config/src/lib.rs[R1884-1918]

+        let mut env_json_auth = crate::npmrc_auth::NpmrcAuth::from_json_env::<Sys>();
+        let env_json_registries = std::mem::take(&mut env_json_auth.scoped_registries);
+        // Gate on creds OR warnings: a malformed `pnpm_config_auth` (or a
+        // non-object sub-field) may push warnings without producing any
+        // creds. Dropping the source in that case would silently discard
+        // the warnings too, since `apply_registry_and_warn` is what flushes
+        // them through `tracing::warn!`. Warrant a seat in the merge chain
+        // whenever there is anything to surface.
+        let env_json_source = (!env_json_auth.creds_by_scope_by_uri.is_empty()
+            || !env_json_auth.warnings.is_empty())
+        .then_some(env_json_auth);
+
// Capture the trusted sources (everything but `project_source`) for
// [`PackageManagerBootstrap`] before the fold below consumes them.
-        let trusted_sources =
-            [env_scoped_source.clone(), auth_ini_source.clone(), user_source.clone()];
+        let trusted_sources = [
+            env_json_source.clone(),
+            env_scoped_source.clone(),
+            auth_ini_source.clone(),
+            user_source.clone(),
+        ];
// Fold high-priority-first: the first present source is the
// base, each lower source fills the gaps it left
-        // ([`NpmrcAuth::merge_under`]).
+        // ([`NpmrcAuth::merge_under`]). `env_json_source` is listed before
+        // `env_scoped_source` so the JSON envelope wins on the rare occasion
+        // both define the same `//host/:_authToken` key — matches pnpm's
+        // TS merge, where `envJsonAuth.auth` is spread after
+        // `envScopedConfig` so later wins.
let mut sources =
-            [env_scoped_source, project_source, auth_ini_source, user_source].into_iter().flatten();
+            [env_json_source, env_scoped_source, project_source, auth_ini_source, user_source]
+                .into_iter()
+                .flatten();
let mut npmrc_auth = sources.next().unwrap_or_default();
for lower in sources {
npmrc_auth.merge_under(lower);

Evidence

env_json_auth.scoped_registries is taken out before trusted_auth is folded and before
build_package_manager_bootstrap runs, while the re-application of those registries happens only
later on the main config. Bootstrap registries are derived via apply_registry_and_warn, which
consumes scoped_registries, so an emptied env_json_source cannot influence bootstrap routing.

pacquet/crates/config/src/lib.rs[1875-1929]
pacquet/crates/config/src/lib.rs[2037-2049]
pacquet/crates/config/src/npmrc_auth.rs[590-599]
pacquet/crates/config/src/lib.rs[2140-2162]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PackageManagerBootstrap` is built from `trusted_auth`, but `env_json_auth.scoped_registries` is emptied via `mem::take` before `trusted_auth` is folded and before the bootstrap is built. The JSON registries are only applied later to `self.registries`, so the bootstrap path can’t see them.
### Issue Context
Bootstrap is intended to use *trusted* sources (user/auth.ini/env/CLI), and `pnpm_config_auth` is explicitly an env-sourced trusted layer; its `registries` should influence bootstrap resolution of the package manager.
### Fix Focus Areas
- pacquet/crates/config/src/lib.rs[1875-1929]
- pacquet/crates/config/src/lib.rs[2037-2049]
### Suggested fix
Avoid stripping `scoped_registries` out of the value that participates in the trusted fold used to build `PackageManagerBootstrap`.
One concrete approach:
1. Parse `env_json_auth`.
2. **Clone** `env_json_auth.scoped_registries` into `env_json_registries` for the later “re-apply after workspace yaml” step.
3. Keep `env_json_auth.scoped_registries` intact so it can contribute to the `trusted_auth` fold and thus to `build_package_manager_bootstrap`.
4. Still re-insert `env_json_registries` after `workspace_yaml.apply_to` to preserve env-over-yaml precedence.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Pacquet re-applies pnpm_config_auth.registries by inserting every key into Config.registries, so
a JSON env entry for default never updates Config.registry and is overwritten when computing
resolved registries. This makes pnpm_config_auth.registries.default silently ineffective in
pacquet, diverging from how pnpm-workspace.yaml and the TS reader treat default.

Code

pacquet/crates/config/src/lib.rs[R2047-2049]

+        for (scope, url) in env_json_registries {
+            self.registries.insert(scope, url);
+        }

Evidence

The pacquet reapply loop inserts all JSON env registries into self.registries, but pacquet’s
resolved registry map always overwrites default from self.registry; workspace-yaml explicitly
special-cases default to set config.registry, so JSON env should do the same to avoid silently
ignoring default.

pacquet/crates/config/src/lib.rs[2037-2049]
pacquet/crates/config/src/lib.rs[1531-1537]
pacquet/crates/config/src/workspace_yaml.rs[764-772]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In pacquet, `pnpm_config_auth.registries` is re-applied by inserting all entries into `Config.registries`. Unlike workspace-yaml handling, the `default` key must update `Config.registry`; otherwise it gets overwritten by `resolved_registries()` which always sets `default` from `Config.registry`.
## Issue Context
- `WorkspaceSettings::apply_to` treats `registries.default` specially (updates `config.registry`).
- `Config::resolved_registries()` always inserts `default` from `self.registry`, overwriting any `default` key that may exist in `self.registries`.
## Fix Focus Areas
- pacquet/crates/config/src/lib.rs[2037-2049]
- pacquet/crates/config/src/workspace_yaml.rs[764-772]
- pacquet/crates/config/src/lib.rs[1531-1537]
## Suggested approach
1. In the `for (scope, url) in env_json_registries` loop, add:
- `if scope == "default" { self.registry = url; continue; }`
- else `self.registries.insert(scope, url)`.
2. Add an end-to-end test in `pacquet/crates/config/src/tests.rs` asserting that `pnpm_config_auth={"registries":{"default":"https://.../"}}` updates `config.registry` (or `config.resolved_registries()["default"]`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In pacquet’s JSON _auth parser, inferred registry routes are stored using
normalize_registry_url(), which only appends a trailing slash and preserves explicit default ports
like :443/:80. This diverges from the TS reader (which canonicalizes via `new
URL(...).href/normalizeRegistryUrl`) and can yield inconsistent
config.registry/config.registries values across implementations for the same logical registry.

Code

pacquet/crates/config/src/npmrc_auth.rs[R296-335]

+            let normalized = normalize_registry_url(&url);
+            let nerfed = nerf_dart(&normalized);
+            if nerfed.is_empty() {
+                self.warnings.push(format!(
+                    "{source}[{label}] ignored: key must be an http(s) registry URL.",
+                ));
+                continue;
+            }
+            for (scope, creds) in scopes {
+                if !is_json_auth_scope(&scope) {
+                    self.warnings.push(format!(
+                        "{source}[{label}][{scope:?}] ignored: scope must be \"@\" or a package scope like \"@org\".",
+                    ));
+                    continue;
+                }
+                let serde_json::Value::Object(creds) = creds else {
+                    self.warnings.push(format!(
+                        "{source}[{label}][{scope:?}] ignored: value must be an auth object.",
+                    ));
+                    continue;
+                };
+                let accepted_creds =
+                    apply_json_auth_creds(self, &nerfed, &label, &scope, creds, source);
+                if !accepted_creds {
+                    continue;
+                }
+                // The host and secret arrive in one trusted value, so the
+                // same entry is a safe source of registry routing — repo
+                // config cannot pick a different destination for this
+                // credential. "@" routes the default registry; a package
+                // scope routes that scope. Last-wins on duplicate scope
+                // keys, matching how yaml and CLI handle duplicate scope
+                // keys.
+                let route_key = if scope == DEFAULT_REGISTRY_SCOPE {
+                    "default".to_string()
+                } else {
+                    scope.clone()
+                };
+                self.json_env_registries.insert(route_key, normalized.clone());
+            }

Evidence

pacquet derives the stored route from the raw JSON key using normalize_registry_url(&url) and
inserts it into json_env_registries, but that helper only appends a trailing slash. In contrast,
the TS reader normalizes via WHATWG URL (parsed.href) and normalizeRegistryUrl, and a test
asserts that an explicit :443 is removed.

pacquet/crates/config/src/npmrc_auth.rs[262-335]
pacquet/crates/config/src/npmrc_auth.rs[847-851]
pnpm11/config/reader/src/loadNpmrcFiles.ts[320-345]
pnpm11/config/reader/test/index.ts[1241-1259]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
pacquet normalizes JSON `_auth` registry URL keys by only appending a trailing slash, so explicit default ports (e.g. `https://reg.example:443`) remain in `config.registry`/`config.registries` as `https://reg.example:443/`. The TS implementation canonicalizes these away (via WHATWG URL normalization), so the same input produces `https://reg.example/`.
### Issue Context
This is a pacquet/TS parity problem introduced specifically on the new JSON `_auth` path. It can lead to surprising routing strings and inconsistent equality/comparison behavior downstream.
### Fix Focus Areas
- pacquet/crates/config/src/npmrc_auth.rs[296-335]
### Suggested fix
Implement a stronger registry URL canonicalization for JSON `_auth` keys (at least: lowercase scheme/host and strip default ports 80/443 for http/https) before inserting into `json_env_registries` (and thus `config.registry`/`config.registries`). Prefer reusing an existing shared URL parsing/normalization utility if one exists in pacquet, otherwise add a small helper dedicated to registry URL normalization that matches pnpm’s `normalizeRegistryUrl` behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In pacquet, NpmrcAuth::from_json_env only appends a trailing slash before calling nerf_dart, so
scheme/host casing (and default-port stripping, which is scheme-case-sensitive) can differ from the
actual request URL and cause JSON-env credentials and inferred registry routes to be missed
unexpectedly.

Code

pacquet/crates/config/src/npmrc_auth.rs[R283-285]

+            let normalized = normalize_registry_url(&url);
+            let nerfed = nerf_dart(&normalized);
+            if nerfed.is_empty() {

Evidence

from_json_env derives normalized via a helper that only adds a trailing slash, and feeds it
directly into nerf_dart. nerf_dart’s parser does not lowercase scheme/host, and its default-port
stripping is case-sensitive on the scheme, so semantically equivalent URL spellings can produce
different nerf-dart keys and miss auth/routing lookups.

pacquet/crates/config/src/npmrc_auth.rs[237-326]
pacquet/crates/config/src/npmrc_auth.rs[836-840]
pacquet/crates/network/src/auth.rs[327-369]
pacquet/crates/network/src/auth.rs[419-421]
pnpm11/config/reader/src/loadNpmrcFiles.ts[286-310]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pnpm_config_auth` JSON registry URL keys are not canonicalized enough on the Rust side. The code currently only ensures a trailing slash before computing `nerf_dart`, but `nerf_dart` preserves the original scheme/host casing and strips default ports only when the scheme equals `"https"`/`"http"` exactly.
This can cause credentials and inferred registry routes to be keyed under a different nerf-dart value than later lookups (which typically come from parsed/normalized URLs), resulting in missing auth headers or routing.
### Issue Context
TypeScript uses `new URL(url)` and then `normalizeRegistryUrl(parsed.href)`, which canonicalizes scheme/hostname casing and default ports before keying auth.
### Fix Focus Areas
- pacquet/crates/config/src/npmrc_auth.rs[283-285]
- pacquet/crates/config/src/npmrc_auth.rs[836-840]
- pacquet/crates/network/src/auth.rs[327-369]
- pacquet/crates/network/src/auth.rs[419-421]
### Suggested fix
- Introduce a Rust-side canonicalization for registry URLs used by `from_json_env` that matches the TS behavior:
- Require http/https.
- Lowercase the scheme and hostname.
- Strip default ports (80 for http, 443 for https) regardless of scheme casing.
- Preserve path semantics and ensure trailing slash.
- Use that canonicalized URL both for:
- `nerf_dart` computation (auth keying), and
- `json_env_registries` routing values.
- Add a unit test for `from_json_env` proving that e.g. `"HTTPS://JSON-Test.Example:443"` yields the same effective nerf-dart key and routing as `"https://json-test.example"` (mirroring the TS test coverage).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In pacquet, json_auth_entry_label() interpolates the raw host_port substring from
pnpm_config_auth into warning strings without escaping control characters. If an attacker can
influence the environment, they can inject newlines/ANSI escapes into logs when these warnings are
emitted via tracing::warn!, obscuring or forging CI output.

Code

pacquet/crates/config/src/npmrc_auth.rs[R1126-1144]

+fn json_auth_entry_label(url: &str, entry_number: usize) -> String {
+    let entry_label = format!("entry {entry_number}");
+    let Some((scheme, rest)) = url.split_once("://") else {
+        return entry_label;
+    };
+    if scheme != "https" && scheme != "http" {
+        return entry_label;
+    }
+    let authority = rest.split(['/', '?', '#']).next().unwrap_or(rest);
+    let host_port = authority.rsplit_once('@').map_or(authority, |(_, host_port)| host_port);
+    let host = match host_port.rsplit_once(':') {
+        Some((host, _)) if !host.contains('[') => host,
+        _ => host_port,
+    };
+    if host.is_empty() {
+        return entry_label;
+    }
+    format!("{entry_label} ({scheme}://{host_port})")
+}

Evidence

from_json_env() generates label via json_auth_entry_label() and interpolates it into warning
strings. Those warnings are later emitted verbatim via tracing::warn!, so any control characters
present in the label will reach logs unchanged.

pacquet/crates/config/src/npmrc_auth.rs[263-280]
pacquet/crates/config/src/npmrc_auth.rs[1120-1144]
pacquet/crates/config/src/npmrc_auth.rs[609-617]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`json_auth_entry_label()` formats a warning label using `{host_port}` derived directly from the `pnpm_config_auth` env var. Because `host_port` is not sanitized/escaped, control characters (e.g. `\n`, `\r`, ANSI escapes) can be embedded into warnings and then logged via `tracing::warn!`, enabling log-forging/obfuscation.
## Issue Context
This is not a secret-leak issue (userinfo/query/fragment are already guarded), but it is a log integrity issue under the repository’s security guidance (env vars are attacker-controlled inputs).
## Fix Focus Areas
- pacquet/crates/config/src/npmrc_auth.rs[1120-1144]
- pacquet/crates/config/src/npmrc_auth.rs[263-280]
- pacquet/crates/config/src/npmrc_auth.rs[609-617]
## Suggested fix
- Sanitize the displayed host/host:port before embedding into the label. For example:
- Build `safe_host_port` via `host_port.chars().flat_map(|c| c.escape_default()).collect::<String>()`, and use that in the `format!(...)`.
- Alternatively, format it using debug (`{host_port:?}`) to force escaping, though this changes the label shape.
- Consider also bounding the label length to avoid extremely large log lines from env input.
- Add a unit test with a host containing `\n` and/or `\u001b[` to assert warnings contain escaped sequences rather than raw control characters.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

appendJsonAuthCreds() looks up JSON_AUTH_FIELD_SUFFIXES[field] on a plain object without an
own-property check, so fields like "__proto__"/"toString" can be misclassified as supported and mark
the entry as accepted. This can incorrectly infer and apply registries[...] = normalized routing
for an entry that provided no actually-supported auth fields, changing registry resolution
unexpectedly.

Code

pnpm11/config/reader/src/loadNpmrcFiles.ts[R307-321]

+  const keyPrefix = `${nerfed}:${scope === '@' ? '' : `${scope}:`}`
+  let accepted = false
+  for (const [field, value] of Object.entries(creds)) {
+    const suffix = JSON_AUTH_FIELD_SUFFIXES[field]
+    if (suffix == null) {
+      warnings.push(`pnpm_config_auth[${JSON.stringify(url)}][${JSON.stringify(scope)}][${JSON.stringify(field)}] ignored: unsupported auth field.`)
+      continue
+    }
+    if (typeof value !== 'string') {
+      warnings.push(`pnpm_config_auth[${JSON.stringify(url)}][${JSON.stringify(scope)}][${JSON.stringify(field)}] ignored: value must be a string.`)
+      continue
+    }
+    result[`${keyPrefix}${suffix}`] = value
+    accepted = true
+  }

Evidence

The suffix lookup is done via a plain object property access (prototype chain visible), and route
inference is gated solely on acceptedCreds returned by appendJsonAuthCreds, so a spurious
accepted=true directly enables registry route insertion. Additionally, any //... key is
considered INI/npmrc-readable, so malformed synthesized keys can enter the merged config pipeline.

pnpm11/config/reader/src/loadNpmrcFiles.ts[231-285]
pnpm11/config/reader/src/loadNpmrcFiles.ts[299-331]
pnpm11/config/reader/src/localConfig.ts[186-199]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`appendJsonAuthCreds()` uses `JSON_AUTH_FIELD_SUFFIXES[field]` on a normal object literal. In JS, property access traverses the prototype chain, so attacker-controlled JSON keys like `"__proto__"`, `"toString"`, or `"constructor"` can return a non-`null` value, bypass the unsupported-field check, and set `accepted = true`. That makes `readJsonAuthEnv()` infer registry routes (`registries[...]=normalized`) even though no supported auth field was provided.
### Issue Context
This code runs on the new `pnpm_config_auth` JSON env var parsing path and is explicitly designed to be robust against malformed input (warn + continue). Prototype-chain field lookups undermine that validation.
### Fix Focus Areas
- pnpm11/config/reader/src/loadNpmrcFiles.ts[309-330]
Suggested implementation direction:
- Replace the object-literal lookup with an own-property guard:
- `const suffix = Object.prototype.hasOwnProperty.call(JSON_AUTH_FIELD_SUFFIXES, field) ? JSON_AUTH_FIELD_SUFFIXES[field] : undefined`
- or use `Object.hasOwn(JSON_AUTH_FIELD_SUFFIXES, field)` where available.
- Alternatively define the suffix map as `Object.create(null)` (or a `Map`) so prototype properties are impossible.
- Ensure `accepted` only flips to `true` when the field is one of the explicitly supported ones.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

getConfig() re-applies --@scope:registry CLI values into packageManagerRegistries without
normalizeRegistryUrl(), potentially leaving a non-canonical base URL (e.g. missing trailing slash)
that can break URL joins or registry matching in bootstrap/self-download flows. This de-normalizes
values that were already normalized when read via getNetworkConfigs() for other registry maps,
creating inconsistent behavior between registries and packageManagerRegistries.

Code

pnpm11/config/reader/src/index.ts[R332-350]

+  const cliScopedRegistries: Record<string, string> = {}
+  for (const [key, value] of Object.entries(cliOptions)) {
+    if (key.startsWith('@') && key.endsWith(':registry') && typeof value === 'string') {
+      cliScopedRegistries[key.slice(0, -':registry'.length)] = value
+    }
+  }
pnpmConfig.registries = { ...registriesFromNpmrc }
if (explicitlySetKeys.has('registry') && typeof pnpmConfig.registry === 'string') {
pnpmConfig.registries.default = normalizeRegistryUrl(pnpmConfig.registry)
}
pnpmConfig.packageManagerRegistries = {
default: normalizeRegistryUrl(trustedAuthConfig.registry as string),
...trustedNetworkConfigs.registries,
+    // Trusted env-inferred routes from `pnpm_config_auth` — the host
+    // and credential arrive in one env value, so bootstrap (self-download
+    // / version switching) honors the same routing as regular installs.
+    ...npmrcResult.envJsonAuth.registries,
+    ...cliScopedRegistries,
+  }

Evidence

The PR introduces cliScopedRegistries by copying raw string values from cliOptions and spreading
them into packageManagerRegistries without normalization. Elsewhere, scoped registries are
normalized through getNetworkConfigs() (which calls normalizeRegistryUrl for @scope:registry
keys), and getPackageManagerRegistries() assumes config.packageManagerRegistries is already in
the correct shape (no normalization occurs there).

pnpm11/config/reader/src/index.ts[332-353]
pnpm11/config/reader/src/getNetworkConfigs.ts[13-21]
pnpm11/pnpm/src/packageManagerRegistries.ts[19-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`cliScopedRegistries` is populated from raw `cliOptions` and then spread into `pnpmConfig.packageManagerRegistries` without passing values through `normalizeRegistryUrl()`. Unlike `getNetworkConfigs()` (which normalizes `@scope:registry` values) and unlike `pnpmConfig.registries` (which is normalized in a later loop), `packageManagerRegistries` currently has no post-normalization step.
### Issue Context
`packageManagerRegistries` is used for pnpm's bootstrap/self-download flows (e.g. `switchCliVersion`) via `getPackageManagerBootstrapConfig()` / `getPackageManagerRegistries()`.
### Fix
Normalize the values as you collect them (recommended):
- When inserting into `cliScopedRegistries`, use `normalizeRegistryUrl(value)`.
Optionally, also add a small normalization pass over `pnpmConfig.packageManagerRegistries` after construction (similar to the `pnpmConfig.registries` normalization loop), but the minimal fix is to normalize `cliScopedRegistries`.
### Fix Focus Areas
- pnpm11/config/reader/src/index.ts[332-350]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools