fix(runners): support instance requirements in EC2 Fleet overrides

[slavab89]

Description

Dynamic EC2 labels allow a workflow to request attribute-based instance selection using InstanceRequirements. This is useful when a workload needs a specific CPU and memory shape while allowing EC2 Fleet to choose among several eligible instance families for Spot capacity.

Today, generateFleetOverrides combines every configured static InstanceType with the dynamic InstanceRequirements object. AWS treats these fields as mutually exclusive within one Fleet override, so CreateFleet rejects the request. The dynamic labels parse successfully, but no runner can launch.

This change gives the two selection modes separate request paths:

• Fixed selection continues to produce one override per subnet and instance type.
• Attribute-based selection produces one InstanceRequirements-only override per subnet, allowing EC2 Fleet to choose from the eligible families.
• Configurations containing both InstanceType and InstanceRequirements are rejected before an AWS request is sent.

Existing fixed-instance behavior is unchanged.

Test Plan

• Added regression coverage proving requirements-only overrides omit InstanceType.
• Added regression coverage proving conflicting fixed and attribute-based selection sends no CreateFleet request.
• Ran the focused EC2 runner suite: 71 tests passed.
• Ran the compute-provider suite: 10 files, 272 tests passed.
• Ran the compute-provider Prettier and ESLint checks.
• Ran git diff --check.

Validated the request against AWS using a temporary launch template without runner userdata or an IAM profile. A requirements-only Spot Fleet request for 4 vCPU / 8 GiB across several allowed compute families completed successfully and selected c7i-flex.xlarge with no Fleet errors. The instance and temporary launch template were deleted afterward.

The project typecheck currently reports existing Vitest 4 configuration errors in untouched configuration files. Those unrelated formatting and type changes are intentionally excluded from this PR.

Related Issues

Fixes #5315. Related to #1400 and follows the dynamic EC2 label support introduced in #5003.

[edersonbrilhante]

@slavab89 Once this error is raised, it will pass along to this call const runnerLabelResolution = await computeProvider.resolveLabelsForRunners(messageLabels); in lambdas/functions/control-plane/src/scale-runners/scale-up.ts:205, then it will pass to the parent caller and it will be retried.

Shouldn't the message be discard?

[slavab89]

@edersonbrilhante Good point. Addressed in 1c40276. Invalid runner-label configurations now raise a typed InvalidRunnerLabelsError. The control-plane catches only that error at the per-label-group boundary and skips the group without adding its message IDs to batchItemFailures, so SQS acknowledges and discards those messages. Other label-resolution errors still propagate and retry. I also added a mixed-batch regression test proving an invalid group is discarded while a valid group continues to launch.

[edersonbrilhante]

@slavab89 Good work.