fix(iot-client): send resetFactory, and let the caller choose it

[heshaoqiong-tuya]

The request body was {"t":…} only. tuya.device.reset requires resetFactory, so the call as shipped came back rejected -- and rejected in the way that reads like a network fault rather than a missing field, since the return code alone says nothing about which parameter the cloud objected to.

The field is not a formality: it picks between the cloud's two meanings for removing a device, and they differ in whether they can be undone. New iot_reset_scope_t makes that the caller's decision:

IOT_RESET_UNBIND_ONLY (false) -- give up the user-device binding, leave the
device's cloud-side data in place. Re-pairing can pick it up again.
IOT_RESET_FACTORY (true) -- also discard the data the cloud holds for this
device, business-specific exclusions aside. NOT reversible: re-pairing
yields a new binding, not the old state.

Same pair of meanings the inbound protocol-11 notice already carries, in the opposite direction -- which is why this is a separate type rather than a reuse of iot_reset_type_t: those constants are named REMOTE_ because they describe a push the cloud initiated, and read backwards on a call the device makes. An enum rather than a bool because a bare true at the call site would not say which one it is, and picking the wrong one cannot be walked back.

Neither scope is a way to reconnect cleanly or recover from an error -- both give the binding up. The header and reference doc say so and point at disconnect/connect instead.

The interface version is 5.0. A first attempt used 3.0 and the cloud answered API_OR_API_VERSION_WRONG on a real device -- an error that does not even say whether the name or the version was at fault. Worth recording because it marks the limit of the mock's version pin: the mock only knows the value this repo told it, so it catches an edit to the constant, not a wrong constant. Only the cloud can confirm the pair, and the test comment now says so.

The mock also requires resetFactory and pins the choice, because nothing in the response can show it: the interface answers with an empty result either way. A devId containing "factory" must arrive with resetFactory=true, any other with false, so a scope that fails to reach the wire is rejected instead of passing silently. Verified by inverting the mapping -- iot_reset_test drops to 2/5. The success envelope still returns an empty result, matching the real interface, which is itself something the suite asserts.

api-activate --release passes IOT_RESET_UNBIND_ONLY so the demo can be re-run; its comment names what a real decommission would pass instead.

Verified: full build clean; ctest --timeout 180 14/14; iot_reset_test 5/5 (1 new); activate_demo builds against the new signature. The api/version pair itself is not verified by any of that -- it needs a real device.