chore: correct stale exports comment

[cryptodev-2s]

Explanation

The comment above expectCorrectWorkspaceExports says packages set up "ESM- and CommonJS-compatible exports", but the function it introduces asserts the opposite:

expectWorkspaceField(workspace, 'exports["."].require', null);
expectWorkspaceField(workspace, 'exports["."].import', null);
expectWorkspaceField(workspace, 'main', null);

References

Part of WPC-1161.

Checklist

• I've updated the test suite for new or updated code as appropriate (comment only)
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed (no published package is touched)
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Low Risk
Comment-only change to Yarn constraint documentation; no enforcement logic or package manifests are modified.

Overview
Updates the Yarn constraints comment above expectCorrectWorkspaceExports so it matches what the rule actually checks.

The old wording implied packages should configure ESM- and CommonJS-compatible exports; the constraint instead requires a single unconditional entrypoint (exports["."].types / default) and explicitly disallows separate require/import conditions plus legacy main/types. No runtime or manifest behavior changes—documentation only in yarn.config.cjs.

^{Reviewed by Cursor Bugbot for commit 7eb228e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Mrtenz]

This comment is accurate actually.

[Mrtenz]

It would be ESM-only if we used exports.import.types/default. exports.types/default keeps it possible to use require(esm) in CommonJS mode.

[cryptodev-2s]

Good catch, reworded here 7eb228e

[Mrtenz]

I mean, the original comment is fine as-is, no?

[cryptodev-2s]

You're right I did miss interpreted this