adopt .nvmrc when auto-updating it is possible

[nedtwigg]

• we don't have an automated process right now
• blocked on Dependabot to update node version in .nvmrc dependabot/dependabot-core#14752
• I'd rather not cobble something together, let's just wait on dependabot

[dormouse-bot]

Confirming the upstream block is still active: dependabot/dependabot-core#14752 ("Dependabot to update node version in .nvmrc") is still open, so the wait-on-dependabot plan stands.

For context on the current state: there's no .nvmrc tracked in the repo right now — the node version is pinned as a hardcoded node-version: 22 across the workflows (ci.yml, release.yml, chromatic.yml, security-audit.yaml). So whenever this lands, the auto-update target would be a new .nvmrc (and those workflow pins, if you want a single source of truth).

[nedtwigg]

• In Supply Chain page: Cargo + bundled-runtime snapshots, provable Node pin #98 I made the call to just let GitHub actions use its judgement to decide what 22 resolves to, but we pin it at release time so that we can vouch for it in the release
• I think I'd rather just have an .nvmrc, but not if we're on our own to keep it up-to-date

[dormouse-bot]

On the "not if we're on our own to keep it up-to-date" condition: that's exactly the gap Renovate's nvm manager fills today — it auto-detects .nvmrc (/(^|/)\.nvmrc$/) and opens PRs to bump the pinned Node version, no custom scripting. So an .nvmrc wouldn't mean hand-maintaining it.

The tradeoff is just that it's a different bot than the one you'd planned to wait on (dependabot-core#14752 is still open), so adopting it is its own call — not the wait-on-dependabot path. If you do go the .nvmrc route, the workflow pins could point at it via setup-node's node-version-file: .nvmrc to keep a single source of truth, while still resolving/vouching at release time the way #98 set up.

Happy to open a PR adding .nvmrc + the node-version-file switch (and a Renovate config, if you want it) whenever you've decided.