Backfills two channels from #347 in one PR:

**`pnpm:progress`** — per-package status transitions. Mirrors
upstream emit at
https://github.com/pnpm/pnpm/blob/086c5e91e8/installing/package-requester/src/packageRequester.ts#L435.
Four `status` values:

- `resolved`: emitted before the tarball download in both the
  no-lockfile path (`install_package_from_registry::run` once the
  registry has picked a version) and the frozen-lockfile path
  (`create_virtual_store::run`'s warm batch + per-snapshot
  `install_package_by_snapshot::run`'s entry).
- `fetched`: emitted from `fetch_and_extract_with_retry` on the
  successful Ok branch — never on attempts that fail and retry.
- `found_in_store`: emitted from `run_without_mem_cache`'s cache-hit
  early returns (prefetched-cas + load_cached_cas_paths) and from
  `create_virtual_store::run`'s warm batch where prefetch already
  settled the bytes.
- `imported`: emitted after `create_cas_files` returns Ok in both
  the no-lockfile and frozen-lockfile paths. `method` is the
  optimistic wire-mapped configured method (Auto/CloneOrCopy →
  clone) — pacquet doesn't surface the per-package resolved method
  past `link_file`'s install-scoped atomic. Tracked under #347 for
  refinement once the resolved method becomes per-package
  observable.

**`pnpm:fetching-progress`** — per-tarball download progress.
Mirrors upstream emit at
https://github.com/pnpm/pnpm/blob/086c5e91e8/installing/package-requester/src/packageRequester.ts#L560.
Two `status` values:

- `started`: emitted once per HTTP attempt at the top of
  `fetch_and_extract_once`, including attempts that resolve to a
  non-2xx status. `size` is the response's `Content-Length`,
  serializing as JSON `null` for chunked / unknown-length responses
  to match pnpm's `size: number | null` shape.
- `in_progress`: emitted from inside the body-streaming loop,
  throttled to 200ms per attempt (matching pnpm's reporter
  coalescing window). Carries the running `downloaded` byte count.

**Threading.** `pacquet-tarball` gains a `pacquet-reporter`
dependency. `DownloadTarballToStore` carries a new `requester:
&'a str` field (the install root); `<R: Reporter>` is threaded
through `run_with_mem_cache`, `run_without_mem_cache`,
`fetch_and_extract_with_retry`, and `fetch_and_extract_once`. The
generic monomorphises away — zero runtime cost. `requester` and
`<R>` cascade up through `InstallPackageBySnapshot`,
`InstallPackageFromRegistry`, `CreateVirtualDirBySnapshot`,
`CreateVirtualStore`, `InstallFrozenLockfile`,
`InstallWithoutLockfile`, and `Install::run`.

**Tests.**

- New wire-shape tests in `pacquet-reporter`:
  `progress_event_matches_pnpm_wire_shape` (covers all four
  status values + the deliberate absence of `packageId` on
  `imported`),
  `fetching_progress_event_matches_pnpm_wire_shape` (covers
  `started` with both `size: Some` and `size: None` → JSON null,
  and `in_progress`).
- New integration tests in `pacquet-tarball`:
  `fetching_progress_and_fetched_events_fire_during_download`
  (asserts `started` fires once per attempt — including 5xx
  retries — and `fetched` fires exactly once on success);
  `found_in_store_event_fires_on_cache_hit` (populates the v11
  store via a first download, then asserts a second call emits
  `found_in_store` and does not emit `fetched` and does not hit
  the network again).

Closes the `pnpm:progress` and `pnpm:fetching-progress` items in
the #347 audit.

…onse coverage

Per Copilot review on #372: the previous fix moved the
`pnpm:fetching-progress started` emit ahead of `send().await` to
ensure connection-level failures still emit, but it always set
`size: None` — even on successful downloads where
`Content-Length` was available. That broke the wire contract for
the percent-gauge use case: consumers couldn't render percent for
fixed-size responses because they never received the size.

Restructure the emit to fire exactly once per attempt, populating
`size` from the response's `Content-Length` when a response head
arrives, and leaving it `None` only when there's no response (DNS
/ connect / timeout failures). Both prior contracts hold:

- Pre-response failures still emit `started` once per retried
  attempt (the original Copilot finding from earlier).
- Successful downloads emit `started` with the populated
  `Content-Length` so consumers can render percent gauges (the
  new Copilot finding).

Tests:
- `fetching_progress_and_fetched_events_fire_during_download`
  extended to assert each `started` event in a 503 + 200 retry
  pattern carries a populated `size` (mockito sends Content-Length
  for both responses).
- `started_fires_for_connection_level_failures` extended to
  assert the connect-refused attempt's `started` carries
  `size: None`.

…etch errors

Two correctness fixes per Copilot review on #372.

**1. `pnpm:fetching-progress in_progress` gating + trailing edge**

Previously: emitted for every download regardless of size, throttled
at 200ms with leading-edge only. The trailing edge was dropped — a
download that finished shortly after the last 500ms tick would
leave consumers stuck at a stale `downloaded` value below the real
total.

Now matches upstream pnpm exactly (`fetching/tarball-fetcher/src/remoteTarballFetcher.ts:143`):

- Skip `in_progress` entirely when `Content-Length` is unknown
  (chunked / streaming responses) or the tarball is smaller than
  `BIG_TARBALL_SIZE = 5 MB`. Most npm packages are well under this;
  per-byte progress for tiny tarballs floods the JS reporter with
  values that would render as 100% before any UI tick can show
  them. `started` still fires for every package; only the
  per-chunk channel is gated.
- Throttle to 500ms (matches `lodash.throttle(opts.onProgress,
  500)`); leading edge fires on the first chunk, subsequent chunks
  are coalesced.
- Trailing edge: a final emit after the body finishes if the last
  in-flight `downloaded` value differs from the last reported
  one. Matches `lodash.throttle`'s default `{leading: true,
  trailing: true}`.

**2. `run_with_mem_cache` deadlock on owner fetch error**

Previously: when the *owning* requester's `run_without_mem_cache`
errored, the function returned without flipping the cache slot to
`Available` or notifying waiters. Concurrent siblings parked on
`notify.notified().await` forever and the install hung — a single
404 could deadlock every later consumer of the same URL.

Now: the owner uses `match` on the result; on `Err` it sets a new
`CacheValue::Failed`, removes the entry from `mem_cache` (so a
fresh request can retry without inheriting the failure), and
notifies waiters. Waiters check for `Failed` and surface a new
`TarballError::SiblingFetchFailed { url }` instead of the
unreachable! panic the previous code would have hit if `Notify`
had been triggered.

The owner's original error stays with the owner (it can't be
cloned past `reqwest::Error` / IO chains).

Tests:
- `run_with_mem_cache_recovers_from_owning_fetch_error` —
  drives two concurrent `run_with_mem_cache` calls against a 404
  endpoint; asserts both terminate (with a 30s wall-clock cap to
  catch the deadlock regression) and both surface errors.