[chriskearney]

The G15 retention host fixture cannot build once start_backend reports the T6031 GPU. The generated mock lacks Platform::DeviceTree, ENODEV/to_errno, dev_warn, and asahi_g15_pmp_report_t6031.

This changes only tools/asahi/g15-retention-tests.py. Existing ownership cases stay. When the extracted backend contains the report call, the fixture checks that setup failures make no report, and that success, ENODEV, and other errors follow graphs-then-report order, stay off other platforms, and keep the nonfatal warning policy.

Validation: the unchanged backend passes all 26 existing cases and four mutation controls. The #258 backend and its effective merge pass 41 cases and nine mutation controls. Independent host checks reran the positive variants and lifetime mutants, then checked 21 separate platform/reply/setup cases; all five new mutants compiled and failed the intended assertions.

Host fixture compatibility only. No kernel change, hardware result, or native module claim. The recorded #258 CI failure stays a failure until that PR runs again on a tree containing the repair. Normal CI, code-owner review and merge queue still apply.

[maralcbr]

Thanks @chriskearney, this looks right to me. Reviewed at cdb9f86. No blockers.

Checked and fine

• It fixes the fixture failure on #258. That PR's host tests (tools) log shows this script failing to compile on the four things added here: dev_warn, asahi_g15_pmp_report_t6031, ENODEV and Platform::DeviceTree.
• The results hold on both sides of #258. Running it with --mutations locally gives 26 cases and 4 mutants on the current base, and 41 cases and 9 mutants on #258's head and on the base with #258's hunks applied. Every mutant fails on its intended assertion.
• The T6031 naming is accurate. t6031.rs is the only config using Platform::DeviceTree.
• The base has moved 38 commits, none touching the script or the files it reads, so CI at this head still applies.

Nits, fine as follow-ups:

• has_t6031_report at tools/asahi/g15-retention-tests.py:340 should go once #258 lands. It's right while that PR is open, but afterwards removing the report call would drop back to 26 cases and still print PASS.
• The case count is hardcoded in the receipt. 41/26 is never compared with the count the run prints.
• The existing failure cases don't assert that no report was made. Only the success paths on the other platforms do, so a report added only on an error path there wouldn't be caught.

Please merge this before #258, which then needs a fresh CI run. It's well behind the base anyway.