feat(rules): add pnpm store and Yarn cache rules

[LouisDeconinck]

What & why

Closes #155

The embedded database classified npm's _cacache but nothing for pnpm or Yarn, so their caches scanned as unknown and never reached the report. This adds two package_manager_cache / safe rules modeled on npm-cache — regenerable downloads whose removal only makes the next install fetch packages again.

pnpm-store covers pnpm's content-addressable store at its real locations:

• **/pnpm/store/** — the store under the pnpm home directory, which is the default on all three platforms (~/.local/share/pnpm/store, ~/Library/pnpm/store, %LOCALAPPDATA%\pnpm\store) and wherever PNPM_HOME points.
• **/.pnpm-store/** — the pre-v7 default that a configured store-dir still commonly uses.

yarn-cache covers both Yarn generations:

• Yarn 1 global cache: **/.cache/yarn/** (Linux), **/library/caches/yarn/** (macOS), **/appdata/local/yarn/cache/** (Windows).
• Yarn Berry: **/.yarn/cache/** (per-project) and **/.yarn/berry/cache/** (global).

The patterns name the cache directories, not their parents, so the non-cache neighbours stay unknown: the pnpm binary and global installs under the pnpm home (pnpm/pnpm, pnpm/global/), and Yarn Berry's release binaries, plugins and SDKs under .yarn (.yarn/releases, .yarn/sdks). Dedicated tests pin that distinction in both directions, and EMBEDDED_RULE_FIXTURES gains a row per rule so the completeness guard keeps holding.

One judgement call worth flagging: a committed .yarn/cache is the zero-installs pattern, so a minority of projects intentionally keep it in git — but its contents are still pure registry downloads that yarn install re-fetches, so safe is consistent with the npm-cache semantics rather than a new class of claim.

Verdicts change only by gaining coverage: previously-unknown paths now classify safe; no existing rule or verdict is altered. The db version stays at 3, matching the npm-cache precedent of bumping at release time rather than per rule.

Checklist

• cargo fmt --all and cargo clippy -p diskern-core --all-targets -- -D warnings are clean
• cargo test -p diskern-core passes: 101/101 (4 new tests)
• Commits are small and focused (one logical change each)
• Doesn't weaken a safety principle (read-only scans, quarantine
  over deletion, deterministic verdicts)
• User-visible changes have a unique fragment in changelog.d/
• PR dependencies and overlapping component edits are identified
• Applicable CI passes; use the merge queue once it is enabled

[Muawiya-contact]

Thanks for contributing again, Louis! This is useful package-manager coverage, but the Yarn verdict needs a safety adjustment before approval. Please account for Plug’n’Play dependencies as described inline and update the regression tests; current CI is green.

[Muawiya-contact]

[P1] Use a conservative verdict for Yarn PnP caches. The PnP loader reads installed packages directly from their cache paths (https://yarnpkg.com/features/pnp), including .yarn/cache and the global Berry cache. Quarantining these ZIPs breaks application imports immediately, even without a committed zero-install cache; it does more than slow the next install. Please use review for paths that can back PnP installs, consistent with the existing node-modules rule, explain the reinstall/restore requirement, and add local/global PnP fixtures that must not classify as Safe. Retain Safe only where the cache is demonstrably separate from runtime dependencies.

[LouisDeconinck]

Done — d95bcc4 splits **/.yarn/cache/** and the global **/.yarn/berry/cache/** out of yarn-cache into a new yarn-pnp-cache rule at review, mirroring the node-modules treatment. The description calls out the PnP loader reading packages straight from the archives and that yarn install must restore them. Yarn 1's global download caches stay safe. Local and global PnP fixtures now assert Review in yarn_pnp_caches_are_review_not_safe, plus a yarn-pnp-cache row in the embedded-rule fixture table.

[LouisDeconinck]

Addressed in d95bcc4.

Split the Berry caches out of yarn-cache into a new yarn-pnp-cache rule (**/.yarn/cache/**, **/.yarn/berry/cache/**) with verdict review — matching the node-modules treatment. The description now spells out the PnP loader reading packages straight from the archives, so quarantining breaks imports until yarn install restores the cache. The Yarn 1 global caches (.cache/yarn, Library/Caches/Yarn, AppData/Local/Yarn/Cache) stay safe since they only ever back downloads.

Regression coverage: yarn_pnp_caches_are_review_not_safe pins both the local and global PnP cache paths at Review, and the fixture table gained a yarn-pnp-cache row so the rule can't silently stop matching. No Rust toolchain in this environment — JSON validated and git diff --check clean; CI will confirm.

[Muawiya-contact]

@LouisDeconinck can review some Open Prs a trigger you to review it.

[Muawiya-contact]

@LouisDeconinck can review some Open Prs a trigger you to review it.

@LouisDeconinck Are you there?

[LouisDeconinck]

@Muawiya-contact done — reviewed #177 (approved; clean guarded render, label fallback is right) and #178 (approved; verified byCategory() already sorts by reclaimable desc so the top-N slice is correct, and f.reclaimable matches the existing total computation). Left one non-blocking a11y nit on #178.

[Muawiya-contact]

Thanks for the update, Louis! The separate yarn-pnp-cache rule now uses review, and the local/global fixtures cover the safety concern; current CI passes, so approved. Also, thank you @LouisDeconinck for reviewing #177 and #178—your careful checks are helping the project move forward. If you’d like, please star Diskern, explore our other projects, and follow Coding Moves.