ci: check the npm package installs and the manifests agree

[lmcorbalan]

Summary

Closes #162

CI had two jobs and neither ran a root npm install, so nothing compiled the service against the dependency set a consumer gets and nothing checked that the published package installs. A third check, package, does both.

Changes

• New package job: an ungated git check-ignore table, then a scope gate, npm run check:deps, npm ci, npm run smoke:registry.
• That table reads both what the build-output ignore rule covers and which file carries it. The same patterns written into registry/.gitignore leave all seven coverage verdicts green while npm applies them to the pack walk, taking the tarball from 24 entries to 8 with the bin target among the losses.
• The gate matches both manifests, registry/, both new scripts, .gitignore, .npmrc and ci.yml, none of which the two existing gates hold.
• The manifest guard runs ahead of the install it guards, matching the daml job's own reasoning.

Acceptance criteria

• All five from the issue are met, with two deliberate divergences. Seven steps, not six: criterion 4 lists no assertion on .gitignore, and every gated step is blind to it, since narrowing registry/**/dist back to registry/dist (the regression 7d04a6c fixed) leaves check:deps and smoke:registry both at exit 0. The ungated step ahead of the gate is what holds it. check:deps before npm ci, not after: it reads four tracked JSON files and needs no node_modules, and npm ci is no second reading of what it names, reddening only where the lockfile can no longer satisfy the range beside it.

Test plan

Automated tests

Existing suites untouched; this adds a check rather than a test.

Manual verification

Every step body extracted from the committed YAML and run. The gate was driven end to end on ten single-file branch shapes (correct on all ten), and its regex over a fixed list of 12 paths that must match and 17 that must not.

Eleven mutations: the ignore rule reds when narrowed, deleted, over-broadened, or pointed at registry/src; check:deps reds on a drifted range; Install reds TS2307 on an import only registry/node_modules resolves, which the registry job compiles green; the smoke reds when a nested ignore file empties the tarball.

Six more for the placement assertion: it reds when the rule moves into registry/.gitignore as **/dist or as bare dist, and when a nested duplicate is added beside a kept root rule, all three of which were green before it and all three of which pack 8 files instead of 24; it stays green when an unrelated rule is added to either ignore file; and outside a git repository it reports the tool error rather than a verdict, with the step still exiting 1.

Also measured, and now what the reordering comment says: npm ci installs clean on a range the lockfile still satisfies (root express widened to ^4.21.0 against a locked 4.22.2) and reds EUSAGE, lock file's express@4.22.2 does not satisfy express@5.2.1 only on the incompatible one, while check:deps reds on both.

Cold clone in the shipped order: all green, tree clean.

Breaking changes

None. No required_status_checks rule exists, so the new context is advisory.

Checklist

• Self-reviewed my own diff
• Tests added or updated
• Docs updated (if applicable)
• No unrelated changes bundled in

Screenshots

None.