hass.windy.lan: resolve health snapshot issues (W1N-70..76) and document findings

- Add tianqi weather recorder patch notes (W1N-75: _unrecorded_attributes)
- Document Bluetooth hci0 RTL8821CS instability (W1N-74) and eMMC lifetime
  10% (W1N-76) as known issues
- Rewrite runbook known-issues section: all snapshot items resolved; link
  hosts doc for the two remaining known issues

hosts/hass.windy.lan.md

@@ -107,6 +107,54 @@ getent hosts hass.windy.lan
 # expect 192.168.55.11
 ```
 
+## Local patches (custom components)
+
+**`tianqi` weather recorder patch (verified 2026-08-13, W1N-75):**
+`/config/custom_components/tianqi/weather.py` has a local patch adding
+`_unrecorded_attributes = frozenset({"hourly_temperature", "hourly_skycon",
+"hourly_cloudrate", "hourly_precipitation"})` to the `WeatherEntity` class.
+Without it, weather.guangzhou's state attributes (~19 KB, dominated by the 4
+hourly_* arrays of up to 48 entries) exceed the recorder 16384-byte limit, so
+the recorder drops **all** attributes for the entity and logs
+`Recorder.db_schema: State attributes for weather.guangzhou exceed maximum
+size of 16384 bytes`. The patch excludes only the 4 arrays from recording
+(live state unchanged; other attributes still stored; ~6.3 KB payload). Backup
+at `weather.py.bak-w1n75`. **Re-apply after any `tianqi` component update.**
+The `_unrecorded_attributes` mechanism exists in Core 2026.8.1
+(`Entity.__init_subclass__` → `state_info["unrecorded_attributes"]`, consumed
+by recorder `shared_attrs_bytes_from_event`).
+
+## Known issues
+
+**Bluetooth hci0 instability — RTL8821CS (verified 2026-08-13, W1N-74):**
+The local Bluetooth controller hci0 is an **RTL8821CS** combo chip on the
+x88 Pro board. Kernel logs show recurring `hci0: hardware error 0x00`,
+`Opcode 0x200c tx timeout` (HCI_LE_Set_Scan_Parameters), `Unable to disable
+scanning: -110`, `Peer device has reset` — the chip hardware-stalls during
+active scanning. HA's `bluetooth_auto_recovery` power-cycle then times out
+after 5 s and retries every ~2 min:
+`bluetooth_auto_recovery.recover: Could not reset the power state of the
+Bluetooth adapter hci0 ... due to timeout after 5 seconds`. The HAOS image
+already ships custom systemd units to cope (`x88-bt-hci-recovery.service` and
+a "Patch HA Bluetooth scanner mode for x88 RTL8821CS" service, visible in host
+journal). **No user impact:** there are **no BLE entities** in HA
+(xiaomi_ble / bthome / led_ble / bluetooth / esphome domains are all empty;
+platforms merely load from stray advertisements). Real IoT devices are Zigbee
+(via Zigbee2MQTT) or WiFi/MQTT/cloud. An ESPHome Bluetooth-proxy ESP32
+(`/config/esphome/bluetooth.yaml`, bluetooth_proxy: active, WiFi `ubnt-haas`)
+is configured but currently offline (ESPHome add-on stopped, port 6053
+unreachable) and produced no entities. Follow-up (optional): disable the
+local adapter and rely on the ESPHome proxy, or stop the bluetooth
+integration entirely.
+
+**eMMC disk lifetime 10% (verified 2026-08-13, W1N-76):** `ha host info`
+reports `disk_life_time: 10` — the boot eMMC (`/dev/mmcblk2`, CJTD4R
+`0xacacc064`, 64 GB) has ~10% life left. `disk_free: 40.2/56.4 GB`. Full
+backup `pre-maintenance-20260813` (slug `411a4ba5`, 144.26 MB) taken
+2026-08-13 covers current config; monitor `disk_life_time` on each health
+snapshot and plan a disk replacement / data-disk migration before the eMMC
+fails.
+
 ## Related docs
 
 - [runbooks/home-assistant-maintenance.md](../runbooks/home-assistant-maintenance.md) — `ha` CLI maintenance runbook + [script](../runbooks/scripts/ha-maintenance.sh)