fix: allow the ADL conformance forks under blockExoticSubdeps

[emmanuel]

Resolves:

[ERR_PNPM_EXOTIC_SUBDEP] Exotic dependency "supertest" (resolved via git-repository)
is not allowed in subdependencies when blockExoticSubdeps is enabled

Why this appeared now

blockExoticSubdeps defaults to true and rejects any transitive dependency resolved from git — which is precisely what the two ADL conformance suite overrides are.

Two things hid it until now, both confirmed in pnpm's source:

1. The check is skipped for lockfile-resolved packages. resolveDependencies.ts gates on resolvedVia != null, with the comment "This is already coming from the lockfile, we skip the check in this case for now." So pnpm install --frozen-lockfile — what CI runs — never trips it. Only a fresh resolution does: pnpm install after a dependency change, Renovate regenerating the lockfile for chore(deps): update adl-lrs-conformance-tests>super-request digest to 6f960be #87/chore(deps): update adl-lrs-conformance-tests>supertest digest to f02f699 #90, or lockfile maintenance (chore(deps): lock file maintenance #45).
2. It's version-dependent. I reproduced it on 11.20.0 and confirmed 11.15.1 (our current pin) does not enforce it.

So this was already queued to break Renovate's override-bump PRs and every future pnpm upgrade, regardless of the immediate trigger.

The fix, and what it costs

blockExoticSubdeps: false.

I looked for something narrower first and there isn't one:

• No per-package allowlist exists. The implementation is a single global boolean (ctx.blockExoticSubdeps && currentDepth > 0 && isExoticDep(...)), with no exception list.
• Making them direct devDependencies doesn't help — verified empirically; the check inspects the subdependency edge, so it still fails with both packages declared at the root.

So the guard goes off for the whole tree, not just these two packages. That's a real if modest reduction in supply-chain protection, and the comment in pnpm-workspace.yaml says so plainly rather than implying the change is free. It's acceptable here because the exposure is narrow and already deliberate: both are dev-only test tooling pinned to immutable commit SHAs and tracked by Renovate, so neither can change content without a reviewed PR. The comment also says to delete the setting rather than keep it if the forks are ever retired (upstream releasing the fixes, or vendoring them) — that's the real long-term fix.

Why the pnpm bump is in the same PR

Pinned pnpm goes 11.15.1 → 11.20.0. Without it, CI runs the one version that doesn't enforce the check, so the fix would be unverified and would break again on the next pnpm bump. The lockfile is unchanged by both the setting and the version bump.

Verification (all under 11.20.0)

Check	Result
Fresh full resolution from empty node_modules	passes (failed before)
Simulated Renovate override-SHA bump — the exact failing command	passes (failed before)
typecheck / lint / fmt:check / lint:arch	clean
Unit tests	293 passed
Integration (pg)	65 passed
ADL conformance (pg, 1.0.3)	37 passed — the actual consumer of the forks
Lockfile churn	none