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]

Good catch. This works fine here for now. But if we need more validations like this one, this will get smelly.
To prevent a refactor in the future, lets create a validation function in /lambdas/libs/compute-providers/aws/ec2/src/control-plane/dynamic-labels.ts, there we can add the config validations, including this one

And in lambdas/libs/compute-providers/aws/ec2/src/control-plane/scale-up.ts we call the validation

    ec2OverrideConfig = parseEc2OverrideConfig(dynamicEC2Labels, defaultBlockDeviceName);
    if (ec2OverrideConfig) {
      logger.debug('EC2 override config parsed from labels', { ec2OverrideConfig });
    }
    <call validation function> with ec2OverrideConfig

[edersonbrilhante]

Could we explicitly type the map callback return as FleetLaunchTemplateOverridesRequest, consistent with the item declaration below? The current code is type-safe through the function return annotation, but the explicit annotation makes the request contract clearer.