device/options for detection_interval on Aqara E1 (RTCGQ15LM) doesn't write to device - only <friendly_name>/set does

Environment

• Zigbee2MQTT 2.13.0
• Device: Aqara Motion Sensor E1 (lumi.motion.acn001 / RTCGQ15LM), battery powered
• Coordinator: Sonoff Dongle-P (Z-Stack)

Repro

1. Publish to zigbee2mqtt/bridge/request/device/options with {"id": "<ieee>", "options": {"detection_interval": 2}}
2. z2m responds status: ok, from: {"occupancy_timeout": 60}, to: {"detection_interval": 2, "occupancy_timeout": 60}
3. Device wakes up (button press or periodic check-in) and reports on zigbee2mqtt/<friendly_name> - payload still shows "detection_interval": 60
4. Only publishing to zigbee2mqtt/<friendly_name>/set with {"detection_interval": 2} actually writes to the device (applied on next wake-up)

Expected / Problem

device/options stores the value only in z2m settings - it does NOT write converter-backed exposed attributes to the device. The log Successfully changed config for device and the status: ok response are misleading: the user believes the attribute was changed on the device, but the device keeps reporting the old value.

Similarly, bridge/request/device/configure does not write exposed attributes either (it only reads + configures reporting).

Question

Is this intended behavior? Should device/options for converter-backed attributes (e.g. detection_interval) attempt a ZCL write like /set does, or should the docs explicitly state that device/options only changes z2m-side settings?

Start by tracing the bridge/request/device/options and bridge/request/device/configure handlers, then compare their behavior with the <friendly_name>/set path described in the report. Done means the behavior is made consistent for converter-backed attributes, or the API and its documentation clearly explain that these requests only change Zigbee2MQTT-side settings.