Add experimental HDS Tasmota grinder TCP mode

[ODevStudio]

Summary

• Adds an experimental HDS scale-side Tasmota grinder TCP mode.
• Uses the plug protocol from ODevStudio/tasmota-nous-a6t-grinder as the source of truth.
• Stores the selected plug by MAC identity, with hostname/IP only as lookup hints.
• Keeps the feature off by default and forces WiFi-on-boot only when grinder mode is enabled.

Notes

• This is scale-side only; no plug firmware changes are included here.
• MAC identity is validation only, not authentication. This remains trusted-local-WLAN only.
• Fast OFF uses the plug emergency OFF path after the TCP session is validated.
• Tare-aware arming and zero-exit protection reduce accidental cutoff when a cup is placed before tare.

[tadelv]

Looks solid as a DRAFT and the feature is off by default, so no blocker. Verified clean: no grinder code runs off the loop/core-0 (no AsyncTCP/BLE/USB task touch, no FreeRTOS task spawned), TCP input parsing is bounded (no overflow path), MAC-as-identity/validation scope is correctly documented as trusted-WLAN-only, tare-aware + zero-exit guard + grind-confirmation correctly handle the ADS1232 ramp blip-to-zero (the PR #71 calibration lesson), and the deep-sleep teardown chain flushes grinder settings before esp32_sleep().

MAJOR to resolve before this leaves DRAFT:

• WiFi.setSleep(false) + esp_wifi_set_ps(WIFI_PS_NONE) for the entire grinding session (grinder_runtime_low_latency.h:49-50, also grinder_discovery.h:79-80). This is the CLAUDE.md #2 WiFi/BLE coexistence footgun — it directly contradicts the explicit comment in wifi_setup.cpp::connectToWifi ("Intentionally not calling WiFi.setSleep(false)"). If low-latency grinder TCP genuinely requires WIFI_PS_NONE, that needs a maintainer decision and a CLAUDE.md carve-out, and concurrent grinder + BLE use should be gated (right now nothing stops both being active).

Minor:

• New globals outside include/parameter.h: b_buttonChordSuppressUntilRelease (hds.ino:27), b_grinderMenuDirectEntry (menu.h:217), grinderSettings/grinderRuntime (grinder_runtime.h:112-113). No cross-task access so no thread risk, but CLAUDE.md says globals belong in parameter.h for discoverability.
• Forcing WiFi-on-boot is a one-way ratchet: grinderOn writes b_wifiOnBoot=true to EEPROM but grinderOff doesn't restore prior state. Once grinder is enabled, WiFi-on-boot stays on even after grinder is disabled. Probably intentional, but it's an undocumented user-facing side effect — document or restore.
• 12s blocking discovery poll (delay(250) loop in grinderEnsureWifiReadyForDiscovery). Acceptable since it's menu-initiated, just noting it blocks processWsPendingCmds / WS drain during that window.

Suggestion (separate from this PR): test_grinder_tcp_contract.py is static source-string matching. As the grinder protocol/state-machine grows, pulling it into pure host-compilable units with real unit tests would catch behavior regressions the grep tests can't — especially for the cutoff/arming/zero-exit logic where the interesting bugs live.