fix(#185): align website guides with selected doc surface

[stiwicourage]

Summary

• Updated the GitHub Pages guide pages so they respect the selected PowerShell or command-line surface consistently.
• Removed end-user Invoke-NovaCli guidance from the website, clarified that Import-Module NovaModuleTools does not make nova available automatically, and made Install-NovaCli requirements explicit for the standalone launcher path.
• This was needed to align the website with issue Fix website guide pages so they respect the selected CLI or PowerShell surface consistently. #185 and the parent direction in Align NovaModuleTools end-user docs and public help with explicit CLI vs PowerShell surfaces. #184: end-user docs should stay surface-consistent and should not mix CLI and cmdlet guidance casually.
• Closes Fix website guide pages so they respect the selected CLI or PowerShell surface consistently. #185. Related to Align NovaModuleTools end-user docs and public help with explicit CLI vs PowerShell surfaces. #184.

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, 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 (project.json, workflow dependencies, release tooling)
• Security-sensitive change
• Documentation-only change
• Other

Review guidance

• Start with docs/getting-started.html, then docs/index.html, docs/core-workflows.html, docs/working-with-modules.html, and docs/troubleshooting.html.
• Focus on whether each page now keeps the selected surface consistent: CLI-oriented website flows should use nova, while PowerShell-only steps such as module installation or direct in-session import behavior stay explicitly PowerShell-only.
• The main trade-off is intentional: the website is now stricter about not presenting Invoke-NovaCli as an end-user workflow, even though it still exists as an internal/public command surface elsewhere.

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:

Executed:
- git --no-pager diff --check -- docs/getting-started.html docs/index.html docs/core-workflows.html docs/working-with-modules.html docs/troubleshooting.html
- HTML parse check on the 5 edited pages
- rg "Invoke-NovaCli" across the scoped website pages

Reason executable validation was skipped:
- This change only updates docs/*.html wording and surface-selection guidance.
- No public command behavior, release/version logic, workflow YAML, or package behavior changed.

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
• RELEASE_NOTE.md reviewed and updated if the change affects public cmdlet usage, CLI usage, configuration semantics, or migration expectations
• 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, release-note, 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:

This is a low-risk website-docs change.

Stable vs prerelease impact:
- None. The change does not affect project.json, Publish.yml, versioning logic, or release flow semantics.

Compatibility impact:
- No product behavior changed.
- The main user-facing change is clearer wording about when the standalone nova launcher exists and when PowerShell cmdlets should be used directly.

Rollback:
- Revert the 5 edited docs/*.html files together if the surface-separation wording needs to be backed out.

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.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[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.

[codescene-delta-analysis]

Code Coverage Gates Passed
Overall Coverage: 100.0% (required = 95%)
New & Changed Code Coverage: 100% (required = 99%)

Review details by gate

• Overall Coverage

  • Pass/Fail Reason:
    The overall coverage gate was checked for all code and meets the goal: 100.0% covered >= threshold = 95%
  • Action:
    You have 281 files with a sum of 2874 covered and 1 uncovered lines of code.

• New & Changed Code Coverage

  • Pass/Fail Reason:
    No executable lines of code changed. (The change touched 0 files).