CI: GitHub Actions pins are 2–3 majors behind (and setup-node is mixed v4/v6) — fix in MJ so it propagates to the Open Apps

## Summary

MJ's CI pins GitHub Actions **2–3 majors behind current**, and because the bizapps Open App repos were seeded from MJ's workflow shape, the same pins propagated across the estate. Nothing is broken today — this is maintenance debt with a security dimension (older majors run on older Node runtimes and stop receiving fixes), and it needs to be fixed here first so the correction propagates outward rather than being re-litigated per repo.

## Current state

MJ core, `origin/next` (`.github/workflows/*`):

| action | pinned | occurrences | latest |
|---|---|---|---|
| `actions/checkout` | **v4** | 44 | **v7.0.1** (2026-07-20) |
| `actions/setup-node` | v4 / v6 (mixed) | 10 × v4, 25 × v6 | **v7.0.0** (2026-07-14) |
| `pnpm/action-setup` | **v4** | 26 | **v6.0.10** (2026-08-03) |
| `actions/upload-artifact` | **v4** | 4 | v4 is current-ish, worth confirming |

`actions/setup-node` being **mixed v4 and v6 within the same repo** is worth noting on its own — whatever the target major is, the two shouldn't coexist.

Downstream, `bizapps-accounting` (representative of the family): `actions/checkout@v4` ×6, `actions/setup-node@v4` ×5, `pnpm/action-setup@v4` ×4.

## Why this is an MJ issue rather than per-repo

The bizapps repos' workflows are derivatives of MJ's — `publish.yml`, `build.yml` and friends were copied and adapted, pins included. Bumping one app repo leaves the rest stale and creates exactly the kind of estate inconsistency that has already cost us elsewhere (see bizapps-common#79 for the branch-protection version of the same pattern). Fixing MJ and propagating gives one decision and one review of the runtime change.

## Suggested approach

1. Land the bump in MJ first, reconciling the mixed `setup-node` majors to one.
2. Propagate to the bizapps repos as a mechanical follow-up, one PR per repo, verified by a green build rather than by inspection.
3. Treat `actions/checkout` v4 → v7 as the one needing real attention: three majors of default-behaviour changes (fetch depth, credential persistence, submodule handling) rather than a runtime-only bump.

## Related, and a trap worth recording

While wiring `changesets/action` in bizapps-accounting we hit a coupling that will apply here too: **`changesets/action@v2` hard-requires Changesets CLI v3** and refuses to run against CLI v2 —

```
Error: This version of the Changesets action is designed to work with Changesets CLI v3.
Changesets CLI v2 is not supported; use Changesets action v1 instead.
```

MJ is on `@changesets/cli ^2.27.12`, so the same gate applies: the action major and the CLI major have to move together. Two further traps from that work, both silent:

- **Action inputs are renamed between majors** (`version`/`title`/`commit` in v1 → `version-script`/`pr-title`/`commit-message` in v2), and **Actions ignores unknown inputs rather than failing** — so a mismatch runs the action's defaults and produces a plausible-looking result. In our case it silently skipped the version script, and the only tell was the PR title falling back to the default.
- **`changesets/action@v2` drops `.npmrc`/`NPM_TOKEN` handling** in favour of trusted publishing, which is a deployment change, not a pin bump.

Filed from the bizapps-accounting release work. Not urgent — the current pins work — but it should be fixed at the source.

Start by inventorying the action references in MJ's .github/workflows/*, including checkout, setup-node, pnpm/action-setup, upload-artifact, and changesets/action. Reconcile the mixed setup-node majors, review checkout behavior and the changesets CLI/action coupling, then verify the updated workflows with a green CI build before propagation.

Written by the indexing model from the issue text.