Check every published export subpath loads in Node

[woksin]

Added

• A CI check that loads every published export subpath in Node, so a published package that cannot be imported is caught before release rather than by a consumer (published ESM contains directory imports, so no node-environment spec can render Dialog or CommandDialog #118)

[woksin]

Reviewer context, kept out of the body.

Scope. This does not attempt the #118 defect itself — that is structurally coupled to PrimeReact 11 (#107), because primereact@10.9.8 ships no exports field and its own dialog.esm.js imports bare primereact/api, so rewriting our specifiers only moves the failure one level in. No component source and no dependency manifest was touched.

What it measures, and the result — see the full table on #118. Headline: 29 checks failed across 21 subpaths; only ./types loads under ESM; and the CJS column shows 12 subpaths still failing on CSS alone, which is the post-#107 world. That is hard evidence the CSS half is independent of PrimeReact 11.

Design. One child node per subpath so a failure cannot poison the next, each loading the real @cratis/components/<subpath> specifier through the workspace symlink into Source/dist/esm or dist/cjs — the resolution a consumer gets, not the source tree. It fails fast with a "run prepare first" message if dist/esm is absent. Non-JS entries (./styles, ./tokens, ./package.json) are existence-checked rather than imported; importing them would always yield ERR_UNKNOWN_FILE_EXTENSION and say nothing about #118.

Non-blocking on purpose, at job level rather than step level, so nothing in the new job — including a broken publish build — can gate a merge while the underlying defect is open. A comment in the workflow says when it should become blocking. Deliberately not added to prepare, which would break publishing immediately, and no npm script was added — Source/package.json is byte-identical.

Semver patch: files publishes only dist, so the script never ships and nothing in the published package changes.

Not verified: the job has not run on a real runner — validated locally and as YAML only. Components tracks no lockfile, so CI may resolve different transitive versions and produce a different failure set. The workflow's paths: filter matches Source/**, so the script triggers it but a workflow-only edit would not; left alone as out of scope. Resolution goes through the workspace symlink rather than an installed tarball — the exports map and dist layout are identical, but I did not npm pack into a scratch project to confirm.