[hCoureau]

The Qrevo 2 Pro (roborock.vacuum.a294) reports generic obstacle recognition, which currently causes discovery to expose obstacle-photo downloads. Give photo downloads a derived discovery predicate that excludes a294 while preserving generic recognition, raw capability flags, and other models. Consumers now receive device.v1_properties.obstacle_photos = None for a294; the S7 MaxV continues to expose the trait. The existing show-photo flag describes a separate vendor UI capability and is unchanged. Other models retain the existing recognition gate because we have no equivalent model-specific hardware evidence for them.

The owner’s app exposes manual remote control without camera viewing. Roborock’s CE manual identifies hardware model RRE0QUI; its external-sensor inventory lists single-line laser obstacle sensing and no RGB camera. The owner reports that the UK Qrevo 2 Pro box label identifies robot model RRE0QUI and dock EWFD63HRR, matching the manual. This change addresses photo discovery only.

Depends on #1028 for the a294 fixture. This draft includes its device-data commits until that PR lands; the photo-specific change is limited to device_features.py, obstacle_photos.py and test_obstacle_photos.py. I’ll update the branch after #1028 lands so the final diff contains only those three files. Related: #1018.

Validation on Python 3.14.10: uv run pytest (2,286 passed, 53 xfailed), uv run pre-commit run --all-files, and uv build pass. All 11 real-broker MQTT tests pass on the combined changes on Python 3.11 and 3.14. The discovery regression fails for a294 with the old gate and passes for both a294 and the RGB S7 MaxV with the fix. Live discovery on the Qrevo 2 Pro also confirms generic recognition remains enabled and obstacle_photos is absent, using fresh authenticated device replies. No photo download, setting change or movement was requested.