Fix handling of non-string values from repository properties API

[mbg]

Fixes #3555.

The repository property API will return repository property objects where the value field is either string or string[]. We do not currently handle the latter.

This PR makes the following changes:

• The first commit updates our type representation of the API responses to account for string[] values.
• The second changes the validation logic to only validate the type of value if it is for a property we care about. This also protects us against future changes to what types of value may be returned by the API.

These two commits are enough to fix the bug. The third commit goes beyond this to enable us to use array-typed properties in the future by:

• Introducing a mapping from known repository properties to the expected API value types (RepositoryPropertyApiType).
• Changing repositoryPropertyParsers to return an object for each known property that contains both a validator function and a parser (PropertyInfo).
• The validator function (.validate) accepts any RepositoryPropertyValue (i.e. string | string[]), checks that it is the expected type, and narrows the type of value if successful.
• The value type validation is now in setProperty, which retrieves the PropertyInfo object for the repository property, calls validate, and then is either able to call parse if the check was successful (and the type narrowed) or throws the validation error.

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.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.

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?

• Feature flags - All new or changed code paths can be fully disabled with corresponding feature flags.
• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

The repository properties feature is already FF-ed. If something goes wrong with this change, we can either disable the existing FF or perform a rollback.

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

Updates repository property handling to support API responses where value can be a string or string[], and validates/parses only properties that this action recognizes to avoid failing on unrelated properties.

Changes:

• Expand API response typing to allow string | string[] for repository property value.
• Refactor parsing to use per-property validate + parse (PropertyInfo) and validate only for known properties.
• Add/adjust unit tests to cover unknown properties with unexpected value types and updated error behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.

File	Description
src/feature-flags/properties.ts	Introduces RepositoryPropertyValue and PropertyInfo-based validation/parsing to avoid throwing on unknown properties and to support future typed properties.
src/feature-flags/properties.test.ts	Updates existing tests and adds coverage ensuring unknown properties with unexpected value types don’t throw.
lib/init-action.js	Regenerated compiled bundle reflecting the TS changes.

[henrymercer]

Looks good! Consider adding a changelog note.