Introduce a type-level check that CodeQL is passed during feature flag lookup if it is needed.

• Use satisfies rather than a type annotation to maintain a more precise type for featureConfig
• Add FeatureWithoutCLI type to record features whose enablement don't depend on the version of CodeQL
• Update FeatureEnablement interface to add a call for FeatureWithoutCLI that doesn't require CodeQL, and make the call for Feature require CodeQL
• Update places that inspect featureConfig to do a safe cast to the former FeatureConfig type using satisfies FeatureConfig as FeatureConfig

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?

Dev change only.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).

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