Update Node.js version requirements for release automation

[stiwicourage]

Summary

• This PR summary is filled from the current branch work in develop relative to main: 183 commits, 451 files
  changed, and 35,737 insertions / 3,368 deletions.
• The branch completes the Nova command-model transition across the public cmdlets and the packaged nova launcher,
  including CLI routing, command help, confirmation behavior, self-update and notification preferences, package creation,
  raw package upload, publish/release workflows, and standalone CLI installation.
• It also reorganizes the private implementation into focused domains such as build, cli, package, quality,
  release, scaffold, shared, and update, adds architectural guardrails and extensive coverage work, and expands
  CI/release automation with ScriptAnalyzer, CodeScene, remapped coverage, semantic-release support, and newer Node.js
  release requirements.
• The branch was needed to make the 2.0 prerelease line coherent for contributors and users: one Nova-oriented command
  surface, clearer internal boundaries, stronger test and coverage enforcement, and documentation that matches the
  actual workflows.
• Recent branch work also includes fixing update-source mismatch behavior and aligning release automation with newer
  semantic-release / Node.js requirements.

Affected area

• nova CLI or command routing
• Public PowerShell cmdlet behavior
• Scaffolding or project.json handling
• Build, test, analyzer, coverage, or CI helper flow
• Package, raw upload, or package metadata workflow
• Publish, release, semantic-release, or GitHub Actions automation
• Self-update or notification preference behavior
• Contributor documentation (README.md, CONTRIBUTING.md, repository workflow docs)
• End-user docs (docs/*.html)
• Command help (docs/NovaModuleTools/en-US/*.md)
• src/resources/example/
• Dependency or manifest changes (package.json, workflow dependencies, release tooling)
• Security-sensitive change
• Documentation-only change
• Other

Review guidance

• Review this as a broad branch-integration PR, not as a single isolated feature.
• Recommended review order:
  1. src/public/ and src/private/{build,cli,package,quality,release,scaffold,shared,update}/ to understand the
     Nova command model, workflow boundaries, and private helper split.
  2. tests/ plus scripts/build/ci/ to review the architectural guardrails, coverage expansion, remapped coverage
     tooling, and CI entry points.
  3. .github/workflows/, scripts/release/, package.json, and package-lock.json for release automation,
     semantic-release, and Node.js/tooling updates.
  4. README.md, CONTRIBUTING.md, CHANGELOG.md, docs/, and src/resources/example/ for contributor and end-user
     documentation alignment.
• Primary paths changed:
  • src/public/
  • src/private/build/
  • src/private/cli/
  • src/private/package/
  • src/private/quality/
  • src/private/release/
  • src/private/scaffold/
  • src/private/shared/
  • src/private/update/
  • tests/
  • scripts/build/ci/
  • scripts/release/
  • .github/workflows/
  • docs/
  • src/resources/example/
• Main trade-offs / limitations:
  • Review risk is breadth: the branch spans command routing, packaging, updates, docs, tests, and release automation.
  • Some areas still need continued follow-up after merge, especially prerelease/update semantics and long-term release
    automation hardening.

Validation

• Invoke-NovaBuild
• Test-NovaBuild
• ./scripts/build/Invoke-ScriptAnalyzerCI.ps1
• ./scripts/build/ci/Invoke-NovaModuleToolsCI.ps1
• Targeted Nova workflow validated (% nova build, % nova test, % nova merge, % nova deploy, % nova publish,
  % nova release, % nova update, % nova notification, or % nova init as relevant)
• Docs/example only; executable validation not needed

Validation notes:

This summary was refreshed from the current branch diff (`main..develop` / `main..HEAD` while on `develop`), not from a
fresh end-to-end rerun of the entire branch as one combined validation step.

Evidence collected while preparing this summary:
- git branch --show-current => develop
- git rev-list --count main..HEAD => 183 commits
- git diff --stat main..HEAD => 451 files changed, 35,737 insertions(+), 3,368 deletions(-)
- git diff --dirstat=files,0 main..HEAD
- git log --oneline --no-merges main..HEAD | head -n 20

The branch clearly contains validation infrastructure and coverage work, including:
- `scripts/build/Invoke-ScriptAnalyzerCI.ps1`
- `scripts/build/ci/Invoke-NovaModuleToolsCI.ps1`
- broad expansion under `tests/`
- workflow and release changes under `.github/workflows/` and `scripts/release/`

This summary does not claim that all historical checks were rerun at summary-generation time. Use the branch CI history
and the relevant workflow runs as the authoritative execution record for the full branch range.

Documentation and release follow-up

• README.md reviewed and updated if contributor workflow, architecture, CI, release, or automation changed
• CONTRIBUTING.md reviewed and updated if contribution expectations or review guidance changed
• CHANGELOG.md reviewed and updated if the change matters to users, maintainers, or contributors
• docs/NovaModuleTools/en-US/ help updated if a public command or CLI behavior changed
• docs/*.html updated if end-user workflows or examples changed
• src/resources/example/ reviewed and updated if the real-world project layout, package model, or upload workflow
  changed
• No documentation, changelog, or example updates were needed

Maintainability, compatibility, and risk

• Code Health / maintainability impact considered
• No breaking change
• Breaking change
• Security-sensitive change
• CI, workflow, or release-pipeline impact
• Dependency-review impact

Risk, rollout, or rollback notes:

Compatibility impact is significant across the branch range:
- legacy MT-oriented public commands and docs are replaced by Nova-oriented names and workflows
- the `nova` CLI syntax, help model, confirmation behavior, standalone installation, package/upload, self-update, and
  release flows evolve substantially
- release automation and dependency/tooling expectations changed, including semantic-release-related Node.js version
  requirements

Rollback is safer when done by theme or PR group instead of as one large revert. Suggested rollback approach:
- isolate the failing area first (CLI routing, packaging/upload, update flow, docs/help, CI, or release automation)
- revert the corresponding commit group or feature PRs instead of attempting one blanket revert of `develop`

Maintainer follow-up / known limitations:
- prerelease ordering and update-candidate policy still need ongoing attention
- broad workflow and dependency changes should be monitored closely after merge/promotion
- reviewer load is high because this range combines architecture, behavior, tooling, and documentation changes

Important

Do not use a public pull request to disclose a vulnerability before coordinated handling.
Use the private reporting path in SECURITY.md for new security issues.

[codescene-delta-analysis]

No application code in the PR — skipped Code Health checks.

See analysis details in CodeScene

Quality Gate Profile: Pay Down Tech Debt
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.