… verifier

The cache record was minimumReleaseAge-shaped (one named field, one
cached-vs-current comparison baked into the lookup). Today there is only
one verifier, but the resolver chain is set up so every resolver can
declare its own — the cache shape should follow.

Move policy-specific state into a `verifiers: Record<string, unknown>`
slot map keyed by a stable verifier id (today: `npm.minimumReleaseAge`).
The cache layer is now policy-neutral: it stores what each verifier
hands it and asks each active verifier's `satisfies(cachedPolicy)`
comparator whether the cached snapshot still covers today's policy.
A cache hit requires every active verifier to be satisfied — a missing
slot or a mismatched policy reruns the gate.

`buildActiveVerifiers` in install/index.ts is the registration point;
future verifiers (jsr trust policy, attestation, etc.) add a slot there
without touching the cache module. Rename the cache file from
`minimum-release-age-verified.jsonl` to `lockfile-verified.jsonl` so the
filename matches the broader scope.

Also bump the test count: new cases cover multi-verifier hits, missing
slots, and the empty-verifier-list path.

The previous commit moved the cache record to a generic `verifiers[]`
shape, but the install layer was still constructing the slots from
`opts.minimumReleaseAge` — duplicating policy knowledge that belongs
upstream. The resolver-side verifier factory already knows its policy
shape; let it declare its own cache slot, parallel to how it declares
its runtime `verify` function.

- `@pnpm/resolving.resolver-base` exports `ActiveVerifier` and switches
  `ResolutionVerifier` from a function type alias to a callable
  interface with an `activeVerifiers: readonly ActiveVerifier[]`
  property. Existing callers (`verify(resolution, ctx)`) keep working;
  new callers read `.activeVerifiers`.
- `createNpmResolutionVerifier` attaches its slot
  (`npm.minimumReleaseAge` with the cutoff and the >=-cached comparator)
  to the returned function.
- `createResolutionVerifier` combinator flattens sub-verifier slots.
- `installing.deps-installer` reads slots from
  `opts.verifyResolution.activeVerifiers` and drops the local
  `buildActiveVerifiers` helper.

Future verifiers (jsr trust, attestation, etc.) plug in by attaching
their slot to their own factory's return — install side untouched.

…turns a list

The previous shape — a callable function with an attached
`activeVerifiers` array — was clunky to construct (Object.assign onto an
async function) and gestured at a fan-out the type couldn't express.
Each resolver-side verifier owns exactly one slot, so the array was
always length 1; the combinator's job was to merge sibling slots, which
the install side can do trivially over a plain array.

New shape:

  interface ResolutionVerifier {
    verify: (resolution, ctx) => Promise<ResolutionVerification>
    activeVerifier: ActiveVerifier
  }

The default-resolver companion is now `createResolutionVerifiers`
(plural) and returns `ResolutionVerifier[]` — an empty list when no
policy is active. The install side fans out over the list per lockfile
entry; each verifier handles its own protocol short-circuit inside
`verify`, so dispatch happens naturally without a combinator.

Renames along the chain: `Client.verifyResolution?` →
`Client.resolutionVerifiers: ResolutionVerifier[]`, same for
`StoreControllerHandle`, `CreateTempStoreResult`, and
`StrictInstallOptions`. Empty arrays everywhere `undefined` used to
live.

Breaking, but npm-resolver hasn't been released since the verifier
landed in #11583, so no downstream consumer is affected.

…sted handle

The `activeVerifier` field was a holdover from when the install side
constructed slots from policy values; with each resolver owning its
slot, the indirection earns nothing — `ResolutionVerifier.activeVerifier.key`
reads as "the verifier's active verifier's key", which is just noise.

Inline the three cache-relevant fields (`key`, `policy`, `satisfies`)
directly onto `ResolutionVerifier`. The cache module declares a narrower
local type `VerifierCacheIdentity = Pick<ResolutionVerifier, 'key' |
'policy' | 'satisfies'>` so it can't accidentally reach for `verify`.

The cache key was just the resolver's identity all along — each resolver
ships one verifier, and a resolver that wants to enforce multiple
policies (e.g. minimumReleaseAge plus a future attestation check)
bundles them into the `policy` object and combines the comparisons in
`satisfies`. With that in mind, calling the field `key` and prefixing it
('npm.minimumReleaseAge') is needless ceremony: the resolver name
('npm') is the slot.

Cache records now look like:
  { ..., "verifiers": { "npm": 1440 } }

instead of the previous:
  { ..., "verifiers": { "npm.minimumReleaseAge": 1440 } }

"satisfies" was grammatically ambiguous — who satisfies whom? The
function decides whether a previously cached run is trustworthy under
today's policy. `canTrustPastCheck(cachedPolicy)` says exactly that
and matches the security framing of the verification gate.

…lots

A verifier's policy isn't really an attribute of the resolver that
attached the verifier — it's an attribute of what was checked. The
\`verifiers: { npm: 1440 }\` slot map prevented two resolvers from
sharing a logical policy (e.g. \`minimumReleaseAge\` honored by both
npm and jsr) and forced every verifier to carry an extra namespace
field.

Flatten the cache record to a single \`policy: Record<string, unknown>\`
bag built by merging every active verifier's \`policy\` contribution.
Drop the \`resolver\` field from \`ResolutionVerifier\`. The npm
verifier now ships \`policy: { minimumReleaseAge: N }\` instead of
\`policy: N\`; its \`canTrustPastCheck\` reads the field it owns from
the merged cached bag.

Shared fields land in one slot (test added: two verifiers contributing
the same \`minimumReleaseAge\` record once). Disjoint fields coexist
naturally. The convention is informal — verifiers checking the same
logical policy name it the same — and the only cost of disagreement
(two verifiers, same field name, different values) is last-writer-wins
on the merge, which matches what the user already typoed into config.

…he record

The cache record had five `lockfile*` prefixed fields (path, hash, size,
mtimeNs, inode) side by side. Group them under a single `lockfile`
object so the prefix only shows up once and the record reads as
"identity + verifiedAt + policy".

On-disk shape:
  {
    "lockfile": { "path": "...", "hash": "...", "size": 154, "mtimeNs": "...", "inode": 12345 },
    "verifiedAt": "...",
    "policy": { "minimumReleaseAge": 1440 }
  }

Git worktrees produce N absolute paths for the same lockfile content,
and a path-keyed cache treats each as separate — every worktree pays
the full per-package registry cost on its first install even though
the content has already been verified elsewhere.

Switch the primary index to the content hash. The path becomes a
secondary index for the same-machine stat shortcut: when we've seen
this exact path with these exact stat values, we trust the cached
hash and skip the file read. When the stat shortcut misses (a fresh
worktree, a CI checkout that reset mtime/inode), we hash and look up
by content.

Lookup order in tryLockfileVerificationCache:

  1. stat(); look up byPath. If the path+stat record still matches,
     hit (microseconds, no file read).
  2. Hash the lockfile; look up byHash. If the content has been
     verified before — at any path — hit. Append a refreshed record
     so the next install at this path takes step 1.

Cache compaction now dedupes by (path, hash) tuple so each worktree
keeps its own stat-shortcut entry without the byHash index losing
older content fingerprints.

Regression test added: a second \`lockfilePath\` under a different
directory but with identical bytes hits the cache via hash.

\`cache: opts.cacheDir ? {...} : undefined\` read like a feature toggle
even though the verification itself runs regardless of cacheDir — only
the memoization is conditional, and cacheDir is always set after config
normalization anyway.

Hoist \`cacheDir\` and \`lockfilePath\` onto the options object directly.
The call site is now a flat property pass-through:

  await verifyLockfileResolutions(ctx.wantedLockfile, opts.resolutionVerifiers, {
    cacheDir: opts.cacheDir,
    lockfilePath: path.resolve(ctx.lockfileDir, WANTED_LOCKFILE),
  })

The function itself decides whether to cache (both fields present →
cache; either missing → run the gate without memoization), which keeps
unit tests that omit the cache wiring on the same code path.