Fix dumpsys parsing quirks for Askey ADT-3 devices (e.g. HTC MagicubOS)

[LuckyType]

Summary

Found and fixed two issues while getting an HTC "MagicubOS" projector (an Askey ADT-3-based Android TV reference device, Android 14) working with Home Assistant's androidtv integration.

1. Missing window-focus fields on dumpsys window windows

On this device (manufacturer=askey, product_id=adt3), dumpsys window windows no longer includes mCurrentFocus/mFocusedApp/mObscuringWindow/imeLayeringTarget etc. — none of the existing per-version command variants (11/12/13+) find a match. Those fields are only present in the unfiltered dumpsys window output. This broke current_app detection, media session state, and launch_app for this device.

Added a new per-device quirk (CMD_*_ASKEY_ADT3), following the same pattern as the existing Askey STI6130 quirk, keyed on manufacturer + product_id.

2. Broken pipe corrupting CMD_SCREEN_ON's dumpsys display fallback

CMD_SCREEN_ON's third fallback check pipes dumpsys display directly into grep -q 'mScreenState=ON'. On devices where dumpsys display produces enough output, grep -q closes its end of the pipe as soon as it finds a match, and the still-writing dumpsys process fails with Failed to write while dumping service display: Broken pipe — text that gets prepended to the result.

This is mostly harmless for exit-status-based callers (e.g. CMD_TURN_ON_ANDROIDTV), but callers that parse the result as a literal "1"/"0" string — specifically screen_on_awake_wake_lock_size, via output[0] == "1" — read the F from Failed... as the first character instead, so an already-on device gets reported as off/unavailable. This exactly matched the symptom I was seeing: the entity stuck showing "off" while dumpsys power clearly showed mWakefulness=Awake, and the on/off toggle appearing to do nothing (because turn_on()'s exit-status check correctly saw the device was already on and skipped sending a redundant power keyevent).

Fixed by buffering the dumpsys display output via command substitution before grepping it, avoiding the race entirely. This isn't device-specific — any device that reaches that third fallback branch (i.e. doesn't match the cheaper Display Power/mScreenOn=true checks) could hit it.

Test plan

• pytest tests/ — all 232 tests pass, tests/test_constants.py updated (new constants + CMD_SCREEN_ON and its derivatives)
• Validated both fixes end-to-end against a real ADT-3-based device (state detection, turn_on/turn_off, launch_app, current_app) — confirmed working live via Home Assistant's androidtv integration after deploying the fix