Fleet-pinned offer queries return no offers for ARM fleets unless cpu.arch is set explicitly

[peterschmidt85]

Steps to reproduce

1. Create a fleet with ARM instances, e.g.:

type: fleet
name: arm-fleet
nodes: 0..1
resources:
  cpu: arm:2..

dstack apply -f fleet.dstack.yml

2. List offers for the fleet without specifying the CPU architecture:

dstack offer --fleet arm-fleet

Actual: no offers are shown, even though the fleet's instances are available.

3. List offers with the architecture set explicitly:

dstack offer --fleet arm-fleet --cpu arm:2..

Actual: the fleet's offers are shown.

The same applies to dstack apply with a run configuration that pins fleets: [arm-fleet] but does not set resources.cpu to arm explicitly: no matching offers are found unless the configuration declares the architecture (which in turn requires image).

Root cause

When resources.cpu.arch is not set, the server defaults it to x86 before offer matching (set_resources_defaults in dstack/_internal/server/services/resources.py; ARM is only inferred when the GPU name is an NVIDIA superchip). For fleet-pinned queries the run requirements are then combined with the fleet requirements, and _combine_cpu (dstack/_internal/server/services/requirements/combine.py) treats the fleet's arm and the defaulted x86 as a conflict — the combination fails and the fleet is excluded from matching entirely, so the query returns no offers.

Notably, the combination logic already handles the unset case correctly: if the run-side architecture were left as None, get_single_value_optional(arm, None) resolves to the fleet's architecture.

Suggested fix

Skip the x86 architecture default when the spec pins fleets, letting the fleet's architecture win via requirements combination (an explicitly requested architecture that conflicts with the fleet should still yield no offers). Alternatively, apply the default after fleet-requirements combination rather than before.