dragonwing-fastrpc/gdsp: malformed single-element tuple in resource requirement causes job to run on non-qcs9075 SoCs

@stanley31huang is already working on this.

Since Sep 7, 2026.

## Bug Description

`dragonwing-fastrpc/gdsp` runs on SoCs it was never meant to target, producing a false-positive failure on hardware that has no GDSP at all.

The resource requirement in `contrib/checkbox-ce-oem/checkbox-provider-ce-oem/units/dragonwing/fastrpc_jobs.pxu:53` is:

```
dragonwing_soc_info.SoC in ("qcs9075")
```

`("qcs9075")` is **not a tuple** — it is a plain `str` (the trailing comma is missing). So `in` performs a **substring** test instead of a membership test. Any `SoC` value that is a substring of `"qcs9075"` (including the empty string) satisfies the requirement.

The sibling jobs `adsp` and `cdsp` on lines 11 and 26 use a correct 5-element tuple and are unaffected.

### Proof that the expression is not doing tuple membership

Evaluated with Checkbox's own `plainbox.impl.resource.ResourceExpression` (checkbox-ng 7.5.1.dev21+gd59039a40):

| `SoC` value | `adsp`/`cdsp` (5-tuple) | `gdsp` (`("qcs9075")`) |
|---|---|---|
| *(no records)* | `False` | `False` |
| `""` | `False` | **`True`** |
| `"qcs"` | `False` | **`True`** |
| `"iqx7187"` | `False` | `False` |

A logical argument that does not even require knowing the `SoC` value on the affected run:

- `adsp`/`cdsp` were **skipped** with `skipped-resource`, so `SoC != "qcs9075"`.
- `gdsp` **ran**, so its requirement evaluated `True`.
- Under correct tuple semantics, `SoC != "qcs9075"` implies `SoC in ("qcs9075",)` is `False`.

Both cannot hold simultaneously unless the expression is doing substring matching.

### Why the resulting failure is not a real defect

The affected run is on a **Qualcomm Hamoa IoT EVK (X1E80100 / Snapdragon X Elite)**, not `qcs9075`:

- Device tree contains **zero** occurrences of `gdsp`, and exactly two remoteproc nodes:
- `remoteproc@6800000` → `qcom,x1e80100-adsp-pas`, fw `qcom/x1e80100/adsp.mbn`
- `remoteproc@32300000` → `qcom,x1e80100-cdsp-pas`, fw `qcom/x1e80100/cdsp.mbn`
- Both DSPs boot fine (`remote processor adsp is now up`, `... cdsp is now up`), so this is not a firmware or DT-disable problem — there simply is no third DSP on this silicon.
- Upstream `drivers/remoteproc/qcom_q6v5_pas.c` lists only `qcom,x1e80100-adsp-pas` and `qcom,x1e80100-cdsp-pas`. GPDSP compatibles exist only for `sa8775p` / `qcs8300`.
- The job invokes `dragonwing_fastrpc_test.sh 5:0 5:1 6:0 6:1`, but upstream `drivers/misc/fastrpc.c` defines domain IDs only up to `GDSP_DOMAIN_ID (4)`. Domains 5/6 do not exist in this kernel.

So `ERROR 0xe: unable to get domain struct 5/6` is correct behaviour being reported as a test failure.

### Suggested fix

```diff
- dragonwing_soc_info.SoC in ("qcs9075")
+ dragonwing_soc_info.SoC in ("qcs9075",)
```

### Related: audit of the same pattern

A sweep of all `.pxu` files for single-element string "tuples" found three more, all in `providers/base`:

```
providers/base/units/submission/jobs.pxu:95: cpuinfo.platform not in ("aarch64")
providers/base/units/info/jobs.pxu:194: cpuinfo.platform not in ("aarch64")
providers/base/units/cpu/jobs.pxu:130: cpuinfo.platform not in ("s390x")
```

These are currently benign because the values happen to match exactly, but they are latent bugs with the same root cause and would misbehave for any platform string that is a proper substring. Happy to fix them in the same PR if wanted.

## To Reproduce

1. Run the `dragonwing-fastrpc-automated` test plan on any board where `DRAGONWING_SOC` is unset or set to a value that is a substring of `qcs9075` (e.g. a Hamoa IoT EVK / X1E80100).
2. Observe `dragonwing-fastrpc/adsp` and `dragonwing-fastrpc/cdsp` are correctly skipped with `skipped-resource`.
3. Observe `dragonwing-fastrpc/gdsp` is **not** skipped and executes `dragonwing_fastrpc_test.sh 5:0 5:1 6:0 6:1`.
4. See it fail with `ERROR 0xe: unable to get domain struct 5` / `... struct 6`.

## Expected Result

`dragonwing-fastrpc/gdsp` is gated to `qcs9075` only, and is skipped with `skipped-resource` on every other SoC — consistent with how `adsp` and `cdsp` behave on the same run.

## Actual Result

The job runs on non-`qcs9075` hardware and fails after ~0.24s for all four domain/session pairs:

```
ERROR 0xe: unable to get domain struct 5
ERROR 0xe: unable to get domain struct 6
```

This produces a false-positive certification failure on hardware that legitimately has no GDSP.

## Environment

- Provider: `contrib/checkbox-ce-oem/checkbox-provider-ce-oem`
- checkbox-ng: 7.5.1.dev21+gd59039a40 (`d59039a403753a4f07871fe4d656d502a06370cf`)
- DUT: Qualcomm Technologies, Inc. Hamoa IoT EVK (X1E80100), Ubuntu 26.04.1 arm64, kernel `7.0.0-1013-qcom`
- Observed in C3 submission for CID `202605-38721` (submission `automated-508886`)

## Additional context

There is a **second, independent issue** observed in the same output, which I have deliberately kept out of this report: `libhap_example.so` prints the domain error three times and then reports `[PASS]`, which masks the true failure count in `dragonwing_fastrpc_test.sh`. I can file that separately.