Address review comments for #3899

[mbg]

Small follow-up to #3899 where there were a few review comments we decided to address in a follow-up.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• Managed - Impacts users with dynamic workflows (Default Setup, Code Quality, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.
• Other first-party - The changes impact other first-party analyses.
• Third-party analyses - The changes affect the upload-sarif action.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.
• Testing/None - This change does not impact any CodeQL workflows in production.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).
• End-to-end tests - I am depending on PR checks (i.e. tests in pr-checks).

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

How will you know if something goes wrong after this change is released?

• Telemetry - I rely on existing telemetry or have made changes to the telemetry.
  • Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
  • Alerts - New or existing monitors will trip if something goes wrong with this change.

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.

[Copilot]

Pull request overview

Follow-up to #3899 to address review feedback by consolidating analyze-action input/env handling tests and making small documentation tweaks in the build script.

Changes:

• Consolidates the two standalone analyze-action tests into a single src/analyze-action.test.ts using test.serial.
• Removes the now-redundant src/analyze-action-input.test.ts and src/analyze-action-env.test.ts.
• Minor comment/string tweaks in build.mjs (including adding a semicolon in generated import lines).

Show a summary per file

File	Description
src/analyze-action.test.ts	Adds consolidated tests covering RAM/threads precedence (env vs action inputs).
src/analyze-action-input.test.ts	Removes prior standalone input-precedence test file (now covered in consolidated test).
src/analyze-action-env.test.ts	Removes prior standalone env-based test file (now covered in consolidated test).
build.mjs	Small comment cleanup and ensures generated import statements include semicolons.

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 1

The base branch was changed.