…ay statuses

Replaces the bespoke `reqwest::Client` builder in `Upstream` with
`pacquet_network::ThrottledClient::new_for_installs()`, so the
registry inherits pnpm's tuned defaults — `User-Agent: pnpm`,
HTTP/1.1, hickory DNS, pool and timeout settings, the concurrency
semaphore, and (later) per-registry TLS routing — instead of
rolling its own and missing every one of them.

Also splits the gateway error response by failure mode rather than
falling back to a blanket `502` on every upstream failure:

* `is_timeout()` → `504 Gateway Timeout`
* `is_connect()` → `503 Service Unavailable`
* anything else / upstream 5xx → `502 Bad Gateway`

Mirrors verdaccio's role in the proxy: the npm client already has
the configured `fetch-retries` policy, so the registry's job is to
surface accurate gateway status so the client's retry loop fires
on truly transient failures and gives up on permanent ones. No
proxy-side retry — see verdaccio v4.0.3 / #1331 for the same
reasoning.

Replaces the buffer-then-serve tarball path with a streaming one:

* Cache hit: open the cached file and stream it as the response
  body (chunked reads, no full-buffer).
* Cache miss: tee upstream chunks into a temp file owned by a
  spawned task, forward each chunk to the client via a bounded
  mpsc channel, and atomically promote the temp file to the final
  cache path on stream completion. Upstream error or client
  disconnect drops the temp file.

Channel capacity (16 chunks) provides natural backpressure: when
the client lags, the upstream-read loop stalls on `send`, so we
don't unboundedly buffer.

Also fixes a tmp-path race: `write_atomic` used to derive
`path.with_extension("tmp")`, so two concurrent writes to the
same cache path collided. Tmp filenames now embed a per-process
atomic counter and the pid; rename stays atomic on POSIX since
src and dst share a directory.

Packuments remain buffered — small JSON, and the URL rewrite
needs the whole document anyway.

Adds 10 tests that close the gaps listed in the previous coverage
review:

* `timeout_error_maps_to_gateway_timeout` (unit test in error.rs) —
  spins a TCP listener that holds connections open, fires reqwest
  with a sub-second timeout, asserts the resulting `is_timeout()`
  error maps to 504. Constructed inside the crate since
  `RegistryError` is `#[non_exhaustive]`.
* `scoped_tarball_is_proxied` — scoped path (`/@scope/name/-/...`).
* `packument_is_refetched_after_ttl_expires` — TTL set to 50 ms,
  asserts the upstream is hit twice across the boundary.
* `stale_packument_is_served_when_upstream_fails` — warms the cache
  against a live upstream, then spins up a second router pointed at
  a dead port and confirms the on-disk packument is served.
* `invalid_package_name_returns_bad_request` — `.hidden` rejected
  at the HTTP layer with 400.
* `concurrent_tarball_fetches_settle_to_one_cache_file` — two
  parallel `oneshot` requests for the same uncached tarball, both
  succeed with matching bytes, exactly one final file remains in
  the cache dir with no `.tmp.*` survivors (validates the
  unique-tmp suffix change from the streaming commit).
* `cache_tmp_open_failure_falls_back_to_uncached_stream` — points
  `cache_dir` at a regular file so `create_dir_all` fails, asserts
  the response still streams correctly.
* `malformed_upstream_json_maps_to_bad_gateway` — upstream returns
  HTML instead of JSON, registry returns 502.
* `upstream_stream_error_clears_cache` — hand-rolled TCP listener
  speaks HTTP/1.1, advertises Content-Length 1 MiB, sends 100
  bytes, drops the socket. Body read errors and no cache files
  remain.
* `client_disconnect_mid_stream_clears_cache` — drops the response
  before consuming the 8 MiB body (large enough that the tee
  channel can't buffer the whole thing), confirms no cache files
  remain after the tee task observes the dropped receiver.

All 26 tests pass; the four timing-sensitive ones (TTL, concurrent,
disconnect, mid-stream error) are stable across five sequential
reruns.

CI surfaced three failure modes the local `cargo test` + `cargo
clippy` run didn't:

* `taplo format --check` reflowed the wide `axum` features array
  into one-per-line.
* `rustdoc -D warnings` flagged a redundant explicit link target
  in `lib.rs` (`[`router`](server::router)` → `[`router`]` since
  `router` is re-exported at the crate root).
* The nightly Perfectionist dylint pass flagged the rest:
  - single-letter generics on `Result<T, E>` and `FetchOutcome<T>`,
    renamed to `Result<Value, Error>` and `FetchOutcome<Payload>`;
  - single-letter function param `s` on `is_safe_segment`, renamed
    to `segment`;
  - single-letter closure params `|e|` over `read_dir` entries,
    renamed to `|entry|`;
  - `tokio::join!(app.clone().oneshot(...), ...)` bound to `let`s
    before the macro call (perfectionist requires impure macro args
    to be evaluated exactly once at the call site);
  - trailing comma added to two multi-line `assert!` invocations.

Verified locally with `cargo dylint --all`, `cargo doc -D
warnings`, `taplo format --check`, and `cargo test`.

…de mock launcher

Three coupled changes that move pacquet's test registry off
Node + verdaccio and onto pnpm-registry itself:

* **pnpm-registry adopts the verdaccio storage layout.** The cache
  now uses `<root>/<pkg>/package.json` + `<root>/<pkg>/<basename>.tgz`
  (flat, no `-/` subdir) — the same shape `@pnpm/registry-mock`
  publishes in its `registry/storage-cache/`. So a populated
  verdaccio storage can be served directly with no conversion step.

* **pnpm-registry gains static-serve mode.** `Config.upstream` is
  now `Option<String>`; a `None` upstream puts the server in
  `--static` mode where cache misses become 404 and the storage
  directory is treated as the authoritative source. The packument
  rewriter is also generalised — it no longer needs to know what
  prefix the source URL had (verdaccio's
  `/{scope}/{name}/-/{scope}/{name}-ver.tgz` quirk vs. npm's
  canonical form), it just extracts the basename and rebuilds.
  `--static` and `--storage` land as CLI flags.

* **pacquet's mock launcher spawns pnpm-registry, not node.**
  `pacquet/tasks/registry-mock` now builds the registry command via
  `assert_cmd::cargo::cargo_bin("pnpm-registry")` against
  `node_modules/@pnpm/registry-mock/registry/storage-cache`. The
  `prepare` step is dropped (storage-cache ships ready to serve),
  the node `launch.mjs` wrapper and `kill_verdaccio` process-tree
  walker are gone, replaced by a one-process `kill_process_by_pid`.
  `@pnpm/registry-mock` stays as a devDep purely for its shipped
  storage fixtures.

Four new integration tests in `pnpm-registry` exercise static mode
end-to-end against the registry-mock storage (packument rewrite,
tarball stream, 404s for unknown package/tarball). 30 tests total
pass; dylint, clippy, and taplo are clean.

…_EXE

`assert_cmd::cargo::cargo_bin("pnpm-registry")` aborts at runtime
when called from a different crate than the binary's owner:
`CARGO_BIN_EXE_<name>` is only injected by cargo for integration
tests of the binary's defining crate, never for `cargo run` of a
sibling crate or for downstream tests. CI surfaced this as:

    `CARGO_BIN_EXE_pnpm-registry` is unset

at the `just registry-mock launch` step.

Replace the call with a small `pnpm_registry_binary()` resolver
that honors `CARGO_BIN_EXE_pnpm-registry` if present, then falls
back to `$CARGO_TARGET_DIR/<profile>/pnpm-registry` (defaulting to
`<workspace_root>/target/<profile>/`) with the profile picked via
`cfg!(debug_assertions)`.

Also wire the `registry-mock` and `test` recipes in `justfile` to
`cargo build --bin=pnpm-registry` first — cargo doesn't implicitly
build the binary of a sibling crate that a downstream test happens
to spawn.

* `pacquet/tasks/registry-mock/src/pnpm_registry_command.rs`
  referenced `port_to_url` with an explicit intra-doc path that
  was both `rustdoc::redundant_explicit_links` (the label already
  resolves the same way) *and*
  `rustdoc::private_intra_doc_links` (`port_to_url` lives in a
  private module, so the link only worked under
  `--document-private-items`). Drop the link syntax — keep the
  inline-code `port_to_url` reference, no target.

* The pacquet CI workflow already covers pnpm-registry tests:
  `Lint and Test` runs `just test`, which builds the
  `pnpm-registry` binary and runs all 30 pnpm-registry tests via
  workspace-wide nextest. The gap is purely in path filters —
  registry-only PRs didn't trigger CI at all. Add `registry/**`
  to both `pacquet-ci.yml` and `pacquet-codecov.yml`, and add
  `registry` to the typos check. Annotate the workflow with a
  comment explaining the intentional cross-stack coverage so
  future readers don't split it.

…dpoint

Pacquet's `add` command fetches `/<pkg>/<tag>` to resolve a
dist-tag to a single-version manifest (the same shape as one entry
of `packument.versions`). Our server only exposed the full
packument and tarball endpoints, so pacquet hit a 404, reqwest
tried to parse it as JSON, and the install failed with
`EOF while parsing a value`. CI surfaced this on the
`should_install_all_dependencies` / `should_add_to_package_json` /
`should_add_dev_dependency` / `should_add_peer_dependency` tests.

Implementation:

* `extract_version_manifest()` resolves the version-or-tag against
  `dist-tags` (falling back to literal-version lookup), pulls the
  matching `versions[v]` subobject, and rewrites its `dist.tarball`
  to point at this server. Reuses `rewrite_tarball_urls`, which
  now handles both packument shape (walk `versions[*].dist`) and
  single-version manifest shape (rewrite top-level `dist`) in one
  pass.

* `load_packument_bytes()` factored out of `serve_packument` so the
  version-manifest handler shares the same cache-then-upstream
  flow (with stale fallback on upstream failure).

* The router now uses unified 2- and 3-segment handlers that
  dispatch on the `@` prefix and the literal-`-` middle segment.
  axum's matchit can't disambiguate `/{scope}/{name}` from
  `/{name}/{version}` at the router level, so the handler does it.

Adds 3 unit tests for `extract_version_manifest` and 3 integration
tests against `@pnpm/registry-mock` storage (dist-tag, literal
version, unknown version → 404). Brings the total to 36 tests.

…serve

Verdaccio in @pnpm/registry-mock is configured with `'**': proxy: npmjs`
(see registry/config.yaml) — the storage holds the scoped fixtures
(@foo, @pnpm.e2e, ...) and anything else is fetched from
registry.npmjs.org on demand. Pacquet's install tests rely on this:
`should_install_all_dependencies` pulls in `is-positive`,
`lifecycle_scripts_run_in_dependency_order` needs `json-append`,
etc. — none of which are in registry-mock's storage.

Switching the launcher to `--static` mode 404'd those requests,
breaking those tests. Restore the verdaccio-equivalent behavior by
spawning `pnpm-registry` in proxy mode against
`https://registry.npmjs.org`, with the storage-cache as the cache
dir.

Set `--packument-ttl-secs 31536000` (one year) so the fixture
packuments stay authoritative: their on-disk mtime is whenever
the npm tarball was built (days/weeks/months old), so any sane
TTL would mark them stale and the refetch would 404 against npm
where the fixtures don't exist.

…nt doc link

CI surfaced two issues my local stable-clippy didn't catch:

* `clippy::collapsible_if` on Rust 1.95 flagged the two nested
  `if let Some(write) = ... { if let Err(err) = ... { ... } }` in
  `streaming.rs::run_tee` introduced in 10fcb85. The fix is the
  let-chain syntax (stabilized in Rust 1.88) — both `let` patterns
  on one `if`, joined by `&&`. Same semantics, cleaner shape.

* `rustdoc::redundant_explicit_links` on
  `seed_storage.rs`'s module doc — `[`runtime_storage`](crate::runtime_storage)`
  and `[`registry_mock_storage`](crate::registry_mock_storage)`
  resolve through the label alone since both are crate-level
  exports. Drop the explicit targets.

…en cargo-nextest is absent

The integrated-benchmark workflow doesn't install cargo-nextest
(it never runs \`just test\`), but my pre-warm step
(af3d2e4) calls \`just registry-mock launch\`, whose recipe
unconditionally invoked \`cargo nextest run --no-run\`. CI failed
with:

    error: no such command: \`nextest\`

Make the recipe a bash conditional: use nextest's pre-build when
it's installed (preserves the Windows .exe-lock fix for the
test workflows that follow up with \`cargo nextest run\`); fall
back to plain \`cargo build --bin=pnpm-registry\` otherwise (good
enough for workflows that only spawn the mock and don't run cargo
tests against it).

Pacquet (and pnpm/npm/yarn) send
\`Accept: application/vnd.npm.install-v1+json; q=1.0, application/json; q=0.8, */*\`
for install metadata. Verdaccio honors it via
\`getPackageByOptions\` → \`convertAbbreviatedManifest\`, stripping
the packument down to only the fields needed for resolution
(name, version, dist, deps, peerDeps, etc.) and tagging the
response with the install-v1 MIME type. The full packument
includes per-version \`_npmUser\`, \`_nodeVersion\`, README
metadata, contributors lists, and so on — none of which a client
needs to pick a version and download a tarball.

pnpm-registry was ignoring \`Accept\` entirely and serving the
full document on every request. For \`lodash\`:

    full:        247 184 bytes
    abbreviated:  77 023 bytes  (3.2× smaller)

The benchmark fixture has ~2.3k unscoped packages and pacquet
fetches each per scenario, so the ratio compounds into a real
+50% wall-clock regression on
\`isolated-linker.fresh-restore.cold-cache.cold-store\` —
identical for pacquet@HEAD and pacquet@main, which is what
clinched it as a server-side issue.

Mirror verdaccio's behavior:

* New \`upstream::abbreviate_packument\` rebuilds the JSON tree
  with the install-v1 field set (top-level and per-version),
  matching verdaccio's exact list from
  \`packages/store/src/storage.ts:convertAbbreviatedManifest\`.
* \`wants_abbreviated(&HeaderMap)\` checks for the install-v1 MIME
  in \`Accept\` (substring match — clients always send it as the
  top-priority option).
* \`packument_response\` either returns the full document with
  \`Content-Type: application/json\` or the trimmed one with
  \`Content-Type: application/vnd.npm.install-v1+json\`.
* Version-manifest endpoint stays full-only (matches verdaccio).

Two new integration tests against \`@pnpm/registry-mock\` storage
cover both shapes — abbreviated drops \`_attachments\`,
\`_uplinks\`, per-version \`_nodeVersion\` etc.; full keeps them.

…ecipe when cargo-nextest is absent"

This reverts commit cbc03c7.

…ed benchmark"

This reverts commit af3d2e4.

…iated form

Real npm packuments store the last-modified timestamp at
\`time.modified\`, not at the top level. My abbreviated form was
copying \`modified\` verbatim — which always missed for npm-sourced
packuments because the source object doesn't have a top-level
\`modified\`. Verdaccio synthesizes both fields explicitly:

    modified: manifest.time.modified,
    readmeFilename: '',

Pacquet's resolver reads \`meta.modified\` in
\`pick_package_from_meta.rs\` (version-pick heuristics) and
\`pick_package.rs\` (freshness check); omitting it pushed the
resolver onto a slower fallback path.

Local head-to-head with the abbreviated form fixed:

    pnpm-registry: 8.162 s ± 0.205 s   (8 runs)
    verdaccio:     8.284 s ± 0.469 s   (8 runs)

Same hardware, same pacquet binary, same lockfile and fixtures.
pnpm-registry is 1.01× faster than verdaccio — within noise. Per-
request server perf is at parity. The remaining +50% gap in CI's
\`isolated-linker.fresh-restore.cold-cache.cold-store\` benchmark
must be artifact (incomplete CI storage coverage, threshold drift,
or runner specifics) rather than a real per-request regression.

Two extra assertions in the abbreviated-form integration test
cover both fields.

Re-introduces a pre-warm step (reverted in 2bcc9fd) now that
local benchmarks proved per-request server perf is at parity with
verdaccio. The remaining +50% gap on
\`isolated-linker.fresh-restore.cold-cache.cold-store\` comes from
the CI cache: verdaccio's \`~/.local/share/verdaccio/storage\` had
been filled organically over *months* of benchmark runs, so by
the time anyone looked it covered every package the lockfile
needs. The pnpm-registry cache is fresh and likely missing
entries — hyperfine's single warmup pass isn't enough to fill in
fresh-install packuments that fresh-restore doesn't touch.

The previous pre-warm used \`pnpm fetch\`, which only downloads
tarballs (packuments stay missing because the lockfile already
pins their resolution). Use \`pacquet install\` against the same
fixture lockfile instead — it issues the exact same
\`Accept: install-v1\` packument lookups + version-manifest
fetches + tarball downloads the timed runs will issue, so the
storage ends up populated with precisely the set the benchmark
requests. \`PNPM_CONFIG_MINIMUM_RELEASE_AGE=0\` disables pacquet's
release-age gate that would otherwise reject the fixture
lockfile.

Restores the \`cargo-nextest\`-or-\`cargo build\` fallback in the
\`registry-mock\` recipe (also reverted in 98ea954) so the
benchmark workflow can call \`just registry-mock launch\` without
\`cargo-nextest\` installed.

…nstall\`"

This reverts commit f748a41.

…DELAY

The CI integrated benchmark was comparing **debug-mode Rust** to
**JIT-optimized V8** — the recipe used \`cargo build
--bin=pnpm-registry\` (no \`--release\`), so the mock server ran
unoptimized while verdaccio always runs through Node's JIT. This
gave pnpm-registry a multi-hundred-millisecond per-iteration
handicap that the integrated benchmark surfaced as a +22%
regression on \`isolated-linker.fresh-restore.cold-cache.cold-store\`,
affecting both pacquet@HEAD and pacquet@main equally (because
pacquet's code is unchanged — only the mock changed).

My earlier local head-to-head (pnpm-registry 8.16s vs verdaccio
8.28s, equal) didn't catch this because I built pnpm-registry with
\`cargo build -p pnpm-registry --bin pnpm-registry --release\`
explicitly. CI's recipe didn't.

Two coupled changes:

* \`justfile\` \`integrated-benchmark\` recipe now pre-builds
  pnpm-registry with \`--release\`.
* The launcher's binary resolver now **prefers
  \`target/release/pnpm-registry\` when it exists**, falling back
  to \`target/debug\` for local dev. The test workflows still get
  the debug binary (they don't trigger the release build); the
  benchmark workflow gets the release one. No env var or
  per-workflow flag needed — having a release artifact override a
  debug one is always the right choice.

Also add \`TCP_NODELAY\` on each accepted socket. Node's HTTP
server enables it by default; hyper 1.x leaves it off. With Nagle
on, Linux's epoll-driven write coalescing adds tens of µs of
per-response delay while waiting for follow-up bytes — invisible
on macOS's kqueue but accumulates across the install fan-out.
Implemented via a \`NodelayTcpListener\` wrapper around the axum
\`Listener\` trait.