feat(hw): repoint Cmd.LED_CONTROL to 0x011B (firmware LED port), hw.led now works

The firmware fork now provides CMD_LED_CONTROL at 0x011B (payload_led_control_t). hw.led already packs the matching <BBBHH> struct + action codes, so repointing the id makes it functional. Adds Cmd.SET_HF_FIELD_TIMEOUT (0x011A, upstream's use of that slot). README caveat updated: hw.led works with the fork, no-op on stock.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -89,10 +89,9 @@ print(t["lf"]["125kHz_V"], t["lf"]["134kHz_V"], t["lf"]["peak_freq_kHz"])
 print(t["hf"]["13.56MHz_V"])
 ```
 
-> ⚠️ **`hw.led` needs firmware with `CMD_LED_CONTROL`** (our LED port — currently a
-> pending follow-up). On stock/current firmware `0x011A` is `CMD_SET_HF_FIELD_TIMEOUT`,
-> so `hw.led` is presently a no-op. The API below is what it will drive once that
-> firmware lands.
+> **`hw.led` needs our firmware fork** (`CMD_LED_CONTROL` @ `0x011B`). It is not in
+> stock upstream firmware — there `0x011A` is `CMD_SET_HF_FIELD_TIMEOUT` and `hw.led`
+> is a no-op. With the fork flashed (the `firmware/` submodule) it drives the LEDs as below.
 
 **LED control** is platform-aware — color names map to the correct physical LED on both PM3 Easy and RDV4. Accepts color names (`"green"`, `"red"`, `"orange"`, `"blue"`/`"red2"`, `"all"`), letters (`"a"`-`"d"`), comma-separated combos (`"green,red"`), or a bitmask int. Pick one action kwarg:
 

pm3py/core/protocol.py

@@ -157,7 +157,8 @@ class Cmd(IntEnum):
     TIA = 0x0117
     BREAK_LOOP = 0x0118
     SET_TEAROFF = 0x0119
-    LED_CONTROL = 0x011A
+    SET_HF_FIELD_TIMEOUT = 0x011A
+    LED_CONTROL = 0x011B  # our firmware fork (0x011A is upstream's SET_HF_FIELD_TIMEOUT)
     GET_DBGMODE = 0x0120
 
     # FPGA