…esolver gh: hardcoding

The @pnpm/resolving.named-registry-specifier-parser package was only
imported by npm-resolver, so its types/parser/built-in alias map are now
collocated in npm-resolver/src/parseBareSpecifier.ts and the standalone
package is deleted.

replaceVersionInBareSpecifier no longer hardcodes 'gh:' alongside 'npm:'
- deps-resolver does not know which prefixes are configured as named
registries, so a single hardcoded entry is the wrong design. Named-
registry specifiers (built-in or user-defined) skip this fast path on
purpose; the cost is one extra metadata fetch on re-resolution rather
than a correctness bug.

replaceVersionInBareSpecifier now accepts a runtime-built list of named-
registry prefixes instead of hardcoding 'gh:'. The deps-resolver merges
the built-in defaults (BUILTIN_NAMED_REGISTRIES) with user-configured
namedRegistries from pnpm-workspace.yaml and threads the resulting prefix
list through ResolutionContext to the call site. Re-installs of locked
gh:/work:/etc. specifiers skip the metadata fetch as they did with the
hardcoded list, and deps-resolver is no longer pinned to a specific
named-registry alias.

The previous version restructured the function around a `body` slice and
rewrote both the lastIndexOf condition and the no-range branch. The same
behavior can be achieved with two minimal changes to the original:
swap the single 'npm:' check for a prefix-list check and add one branch
for the new `<alias>:<version_selector>` form. The original
versionDelimiter logic stays untouched.

Repeating the same description on each PnpmSettings/Config/ResolverFactoryOptions/
ResolutionContext field doesn't match the repo's convention. Also collapse
DEFAULT_GH_REGISTRY/BUILTIN_GH_ALIAS into the BUILTIN_NAMED_REGISTRIES literal.

…ge name

Unifies the npm: parser with the named-registry shape (gh:^1.0.0): when
the body of an npm: specifier is a bare semver range or version, treat
the outer dependency alias as the package name. Previously npm:^1.0.0
was parsed as "package literally named ^1.0.0" and 404'd. Restricted to
semver.validRange to preserve npm's package-aliasing meaning for tag-like
bodies (npm:is-positive, npm:latest).

* Relax named-registry parser to accept unscoped names (work:lodash@^4) and
  fall back to any (scoped or unscoped) outer alias for <prefix>:<range>.
  Drops the validateScopedPackageName helper; scoped-name validation stays
  inline for the @-prefixed branch.
* Optimize replaceVersionInBareSpecifier hot path: check 'npm:' first then
  for-loop over namedRegistryPrefixes, avoiding a per-call array allocation.
* Guard replaceEnvInStringValues against arrays so a YAML list under
  registries:/namedRegistries: surfaces as a config error instead of being
  silently coerced to {0: ..., 1: ...}.

…gistry

Both resolvers had near-identical bodies: parse spec → look up registry URL
→ getAuthHeaderValueByURI → pickPackage (with NoMatchingVersionError) → build
id/resolution. Extract a pickFromSimpleRegistry helper that returns the
common result fragment, and unify calcJsrSpecifier/calcNamedRegistrySpecifier
into a single calcPrefixedSpecifier. Net -89/+54 lines. Side effect: jsr
now also forwards publishedByExclude and optional through to pickPackage,
matching the named-registry resolver and the type signature it already had.