wsen-hids: read_one_shot() times out reliably on STeaMi hardware

[nedseb]

Summary

WSEN_HIDS.read_one_shot() (and the same path inside read() when the
chip is in power-down) raises WSENHIDSTimeoutError("One-shot measurement timeout") on the real STeaMi board, despite the chip
being healthy and responsive on the bus.

Reproduction

Fresh make micropython-deploy of MicroPython on a STeaMi board,
then:

mpremote mount lib/wsen-hids run lib/wsen-hids/examples/one_shot_mode.py

→ raises WSENHIDSTimeoutError from device.py:401 in
read_one_shot() on the first call.

continuous_mode.py on the same board produces correct, stable
values (RH ≈ 33–34 %, T ≈ 31 °C), so the chip is healthy and
calibration / I2C transport work — the failure is specifically the
ONE_SHOT trigger path.

Observed register state (matching investigation in steamicc/arduino-steami-lib PR #131)

After trigger_one_shot():

• CTRL1 = 0x84 (PD=1, BDU=1, ODR=00) — correct
• CTRL2 = 0x01 (ONE_SHOT latched) — never auto-clears
• STATUS = 0x00 — H_DA / T_DA never go high
• state stays frozen past 500 ms (well over the documented worst-case
  conversion time at default AV_CONF)

Cross-implementation check

The Arduino driver in steamicc/arduino-steami-lib was rewritten
recently against the same chip and hits the same behaviour from
its own, independent code path. So this is not a driver bug in either
implementation — it's either a chip-state issue specific to this
silicon (Würth 2525020210001) or a documented-but-undocumented
requirement we're both missing.

Workaround

set_continuous(ODR_1_HZ) works reliably; consumers that don't
strictly need one-shot can be told to use continuous mode after
begin().

Asks

1. Has anyone reproduced this on a different STeaMi unit, to rule out
   a per-board issue?
2. Anything we can do at the driver level (e.g. AV_CONF reset, CTRL2
   pre-clear, extra delay after PD wake) that we haven't tried? My
   investigation tried explicit AV_CONF reset to 0x1B, CTRL2 clear,
   reboot() (CTRL2.BOOT), delays up to 50 ms after PD wake-up, and
   read-modify-write on CTRL2 — none of those let the conversion
   engine fire.

[nedseb]

Quick update from the Arduino side after looking at both upstream
reference drivers:

• Würth Sensors-SDK/WSEN-HIDS_2525020210001 — HIDS_enOneShot()
  is just a CTRL2.ONE_SHOT setter. The shipped
  examples/quickStart/main.c never uses it: it sets continuous mode
  via HIDS_setOdr(odr1HZ) and reads via HIDS_getTemperature /
  HIDS_getHumidity. Würth doesn't ship a working one-shot example.

• stm32duino/HTS221 (same silicon family) — the low-level
  HTS221_StartOneShotMeasurement exists, with the comment "Set
  ONE_SHOT bit to start a new conversion (ODR mode has to be 00)".
  But the HTS221Sensor high-level wrapper never calls it.
  Its begin() pre-selects ODR=1 Hz and Enable() flips PD=1, and
  reads route through continuous-mode polling only.

So the auto-trigger via one-shot pattern in both this driver and the
Arduino sister driver was a "feature" no upstream reference actually
ships. The Arduino driver has now been switched to auto-bring-up via
continuous mode at 12.5 Hz inside read()
(arduino-steami-lib commit f5e0d6d),
matching the stm32duino pattern; explicit triggerOneShot() /
readOneShot() are still exposed but no longer in the default flow.

Suggesting the same shape for _ensure_data() here:
when the part is in power-down, call set_continuous(ODR_12_5_HZ)
instead of trigger_one_shot(), then poll data_ready() with a
~200 ms timeout. Keeps read_one_shot() available for callers who
explicitly want the (unreliable) one-shot path.