touch: retry + hard-reset when FT5426 boots into wedged 0xff state

After a long bench session of taps + power cycles, the FT5426 on this
unit started returning dev_mode=0xff on every read. The polling loop
interpreted that as 15 simultaneous touches forever (td_status bits
0..3 all set), wedged `was_down=true` permanently, and no tap or
long-press ever fired — the screen looked dead.

Two layers of defence in touch_init:
  1. retry the dev_mode read up to 10 × 30 ms in case the chip is just
     slow to come up after PC_RST_TP_N is released.
  2. if still stuck, pulse PC_RST_TP_N via a new
     display_touch_reset_pulse() helper (drop reset for 20 ms then
     release + 50 ms settle), then retry the read another 10 × 30 ms.

Plus a polling-loop sanity check: an FT5x06 supports max 5 simultaneous
points, so a TD_STATUS lower-nibble value > 5 is bogus and the poll
cycle is skipped. That keeps a wedged chip from producing phantom
"15 touches" reports if it slips into 0xff during runtime.

If both attempts still report 0xff, we log loudly and let the polling
task run — it harmlessly drops cycles via the >5 sanity check. Wake
still works via POST /state from Scrypted; this only disables touch
gestures on a hardware-stuck boot.

0 files changed, 0 insertions, 0 deletions