Add the package CI job

[lmcorbalan]

User story / Problem statement

CI has two jobs, registry and daml. Neither runs a root npm install, so
nothing on the pull-request path compiles the service against the dependency set
a consumer gets, and nothing checks that the published package installs at all.
A change that empties the tarball, or leaves a runtime import declared only in
registry/package.json, is green on both existing checks and breaks only in a
downstream repository.

Expected outcome

A third status check, package, that installs from the root, checks the two
manifests agree, and runs the install smoke test.

Acceptance criteria

• A job named package in .github/workflows/ci.yml, alongside registry
  and daml
• Its scope gate is per-step, matching the two existing jobs, so a scoped-out
  pull request reports a green check carrying the scope log rather than
  skipped
• The gate matches package.json, package-lock.json, registry/, both new
  scripts, .gitignore, and ci.yml
• Steps, in order: checkout with full history, scope, setup-node keyed on the
  root lockfile, npm ci, npm run check:deps, npm run smoke:registry
• The gate regex is verified against a fixed list of paths that must match and
  paths that must not

Technical notes

• .gitignore belongs in the gate. The rule that keeps registry/dist out
  of git is the same rule that decides whether it reaches the tarball, so an edit
  there can empty the package while touching nothing else the gate would catch.
• The root npm ci runs prepare, so this job compiles registry/src against
  the root dependency set, which is the set a consumer gets. That is a
  different compile from the registry job's, and it is the one that would catch
  a type package arriving only through registry/node_modules.
• A job's name is the status check context a ruleset would match on. Neither
  existing check is required yet, so adding this one changes no merge
  requirement; naming it consistently now is what makes it requirable later.
• Copy the existing scope step verbatim, including its three-attempt fetch retry.
  A blip on that fetch would otherwise red a check having verified nothing.
• This job's own pull request touches ci.yml, which is in all three gates, so
  all three jobs run on it. The Daml job's gate also matches package.json and
  package-lock.json, so the two manifest issues in this epic each trigger a
  full Daml build; that is expected, not a misconfiguration.

[lmcorbalan]

One correction to the technical notes, from a probe run while reviewing #159. The conclusion is right and .gitignore does belong in the gate, but the stated mechanism is not what happens, and the difference changes what this job can usefully assert.

.gitignore belongs in the gate. The rule that keeps registry/dist out of git is the same rule that decides whether it reaches the tarball, so an edit there can empty the package while touching nothing else the gate would catch.

The root .gitignore cannot subtract from the files allowlist. Only a nested ignore file can. npm applies a nested ignore file to the pack walk even for a path that the root files names, while files outranks the root ignore file. That asymmetry is the whole reason #159 moved the rule up rather than deleting it.

Measured on a detached worktree at ca9ebca, the commit that moved it: with registry/dist in the root .gitignore and no dist rule in registry/.gitignore, npm pack --dry-run lists 24 files including all 16 registry/dist/*.js. The root rule is inert with respect to the tarball. An edit to it cannot empty the package; an edit that reintroduces a rule in registry/.gitignore can, and that mutation is already in #161's list.

Two things follow.

1. .gitignore is currently in no gate at all, which is a better argument for the criterion than the one in the note. Neither existing pattern matches it: the registry job's ^(registry/|\.github/workflows/ci\.yml$) and the daml job's longer alternation both miss. A pull request touching only that file would report two green checks having verified nothing. That is not what happened on #165, whose diff also touched package.json and so pulled the daml job in, but a follow-up that re-anchors or narrows the rule on its own would land unverified.

2. The failure a root .gitignore edit can actually cause is not a packaging failure, so a pack assertion will not see it. It is the one 7d04a6c fixed: an anchored registry/dist stops ignoring a dist at any other depth, so build output under registry/src or registry/test silently becomes committable. Worth deciding whether this job asserts anything about that (a small git check-ignore table over a fixed list of paths would do it, and is the A/B that caught the narrowing in the first place), or whether .gitignore sits in the gate purely so that #161's smoke run is re-executed when the file changes. Either is defensible; the note as written implies a third thing that the pack cannot deliver.