ci: validate the published package against Angular 17-22

[ismailza]

Closes #11

Summary

The workspace builds on Angular 22 only, so nothing verified the range the package claims to support. This adds a matrix that installs the packed tarball into a throwaway consumer project per Angular major and validates it
there, plus the artifact checks that make that validation meaningful.

Motivation

Three concrete gaps, each capable of shipping a broken release unnoticed:

1. CI validated a different package than the one published. npm run build produced no LICENSE or CHANGELOG.md — those were copied in by a step in the release workflow alone. Anything checking dist/ was inspecting something consumers never receive.
2. Nothing ran the Angular linker. The package ships partial (unlinked) declarations. Type-checking and JIT both bypass the linker, but it is what processes them during a real application build — so a package could pass a type-check and still fail in every consumer project.
3. >=17.0.0 was unfalsifiable. No upper bound meant new majors entered the supported range the day they released, and there was no signal at all for the majors in between.

What this does

Per Angular major, three checks — each covering what the others structurally cannot:

Check	Catches
ngc type-check	breaks between the shipped .d.ts and that version's Angular types
ng build (production)	Angular linker failures, AOT and bundler breakage
Runtime smoke	JIT compilation, injector behaviour, exports map resolution

The build leg asserts no partial declarations survive into the bundle (proving the linker ran) and that library code is still present (proving the fixture wasn't tree-shaken away, which would make the check pass vacuously).

Supporting changes:

• Peer range bounded to >=17.0.0 <23.0.0, and the CI matrix derived from it — the versions tested cannot drift from the versions claimed.
• LICENSE/CHANGELOG.md staging moved into postbuild, so npm run build produces a complete package and the duplicate step leaves the release workflow.
• Packed contents and the exports map verified in both workflows.
• Node matrix (22, 24); every setup-node aligned on 24, since Angular 22 requires ^22.22.3 and each publish job packs its own tarball from the shared artifact — a differing bundled npm would change the shasum between registries.
• Compatibility table published to the run summary.

Verification

All six majors pass all three legs locally on Node 24. Both failure modes were confirmed to actually fail — an injected type error and a wrong runtime assertion each exit non-zero.

Not verified locally: Angular 22 on Node 22. Angular 22's own floor is ^22.22.3, above the Node 22 available on this machine, so that single cell rests on setup-node resolving a recent 22.x. First CI run will confirm it.

Reviewer notes

• Bounding the peer range means consumers on a future Angular 23 get a peer warning until it is widened. That is the intent, but it is a real support commitment.
• The compat matrix is 12 jobs, and the older CLIs pull ~800 packages each.
• compat/** is ESLint-ignored: it resolves the library from an installed tarball, so it sits outside this workspace's type graph. IDEs will show unresolved-import errors there by design.
• The peer range change is carried by a ci: commit, so release-please will not cut a release for it. Deliberate — flagging in case you would rather it ship on its own.

🤖 Generated with Claude Code