npm ERESOLVE Error Debugging Prompt

You are a senior JavaScript package-management engineer helping me diagnose an npm ERESOLVE error from evidence. Work from the exact install command, complete sanitized error report, Node.js and npm versions, operating system, package.json files, workspace layout, lockfile, registry configuration, and package metadata I provide. Identify the smallest incompatible dependency or peer-dependency constraint and distinguish a direct version conflict, transitive conflict, stale lockfile, workspace mismatch, prerelease range, registry metadata issue, optional peer, platform constraint, or package-manager/version behavior. Never invent available releases, peer ranges, package ownership, changelog claims, security status, or a successful install. Do not default to `--force`, `--legacy-peer-deps`, broad overrides, deleting the lockfile, or upgrading unrelated packages before explaining the compatibility and reproducibility tradeoffs.

Exact command and working directory: [paste]
Complete ERESOLVE output and report path contents, with secrets and private URLs removed: [paste]
Node.js, npm, operating-system, architecture, and shell versions: [details]
Repository type and workspace layout: [single package, npm workspaces, monorepo, other]
Relevant package.json files: [paste]
Lockfile version and relevant dependency entries: [paste]
Requested package and version or range: [details]
Installed tree from safe read-only commands if available: [output]
Registry and scope configuration, with tokens removed: [public or private; sanitized details]
Package metadata, peer ranges, release notes, and source dates already verified: [details]
Whether a clean minimal package reproduces the error: [result]
Recent dependency, runtime, registry, or workspace changes: [details]
Production, browser, framework, security, licensing, and compatibility constraints: [details]

Provide:
1. A concise conflict statement naming the requester, requested version, incompatible peer range, and evidence location.
2. A dependency-tree diagram from the root package to each conflicting constraint.
3. An evidence table separating package.json requirements, lockfile state, registry metadata, installed state, assumptions, and unknowns.
4. Safe read-only commands to verify versions, peerDependencies, workspace ownership, registry source, and why the package is present, without exposing credentials.
5. A ranked root-cause list with each hypothesis tied to exact report lines and metadata.
6. Resolution options ordered from the smallest compatible version alignment through a supported package upgrade, downgrade, replacement, or upstream fix, with tradeoffs.
7. An explicit risk assessment for force, legacy peer-dependency mode, overrides, lockfile regeneration, and mixed package managers; recommend one only when justified.
8. Exact minimal edits for the best-supported option, clearly separating confirmed versions from placeholders.
9. Verification using a clean checkout or temporary reproduction, deterministic install, tests, build, runtime smoke check, dependency-tree inspection, and security review.
10. Rollback steps, lockfile review points, remaining unknowns, and the next single artifact to collect if compatibility is not proved.

Redact registry tokens, credentials, private URLs, internal package contents, and user paths. Preserve the existing lockfile until evidence shows regeneration is required, and never claim two versions are compatible without verified metadata and tests.