feat: support Node.js content in the gallery release pipeline

[amylin1249]

Fixes #373: Makes the release/CI pipeline understand Node.js content

Changes (review commit by commit)

• extension-list.ts: derive requiredEnvironment.nodejs from engines.node in the extension's package.json (Connect's single source of truth; it doesn't read a nodejs field from the manifest).
• lint: require engines.node for nodejs app-mode extensions.
• integration test action: install a Node runtime into the running Connect container for nodejs extensions (the published Connect images ship no Node), enable it, and restart so Connect loads it.
• CONTRIBUTING: document the engines.node convention and the minimumConnectVersion >= 2026.06.0 rule.

Validation

This PR is infra-only: no Node.js example ships here (in-development examples live in connect-staging-extensions; the real one is the Express app, #374). So the Node provisioning is validated externally:

1. In CI (this repo): on a probe branch, a hello-world Node extension deployed successfully on preview, release, and 2026.06.0:
   https://github.com/posit-dev/connect-extensions/actions/runs/28797948148
2. End-to-end in staging: connect-staging-extensions#36 adopts this exact harness with a real Node.js hello-world. Its CI is green, and the example was deployed to dogfood, where it runs ({"message":"Hello from Node.js on Posit Connect!"}) and Connect recognizes it as Node.js content (Node.js logo). Confirms the approach works on a live Node-enabled Connect, not just in CI.

[github-actions]

Extension release summary

😴 Changed but won't release

The following extensions have code changes but the manifest version hasn't been incremented:

• package-vulnerability-scanner: manifest version 3.0.6 ≤ released version 3.0.6
• publisher-command-center: manifest version 0.0.8 ≤ released version 0.0.8
• runtime-version-scanner: manifest version 1.0.5 ≤ released version 1.0.5
• usage-metrics-dashboard: manifest version 1.0.15 ≤ released version 1.0.15

If you intended to release these changes, update the version field in each extension's manifest.json.

See the contributing guide for details.

[karawoo]

I think there's an inconsistency here between how the linting step and the extension-list.ts handle it if engines.node is missing. Linting fails, but the extension-list.ts code doesn't -- I think we should be consistent.

[karawoo]

some non-nodejs extensions can have a package.json (package-vulnerability-scanner does, for example) so I think we should combine this with a check for whether the manifest's appmode is "nodejs"

[amylin1249]

Fixed in 4f375ea - it should now check for metadata.appmode == nodejs, so a non-nodejs extension that ships a package.json (like package-vulnerability-scanner) won't get a nodejs requirement pulled in here.

[amylin1249]

I think there's an inconsistency here between how the linting step and the extension-list.ts handle it if engines.node is missing. Linting fails, but the extension-list.ts code doesn't -- I think we should be consistent.

Fixed in 4f375ea - extension-list.ts now errors on a nodejs extension missing engines.node, matching the lint check so the two are consistent.