Persist the RKP-only knobs so a toggle survives a reboot

[JingMatrix]

The two remote_provisioning.*.rkp_only properties gate whether keystore2 provisions attestation keys only through RKP or may fall back to a batch key; turning them off is what restores Strong Integrity on a device that ships them on. They are plain system properties, not persist.*, so a live resetprop is gone on the next boot — and a vendor .prop that init re-applies each boot can even reassert the on default (#236). The WebUI toggle therefore reverted on every reboot, and integrity had to be won back by toggling again.

The chosen values are now kept in /data/adb/teesim/rkp.json and re-forced onto their properties at daemon start, in applyRkpProps, right after the verified-boot props — overwriting only on a live-vs-stored mismatch, so a steady state does no work. enable_rkpd is persist.device_config and already survives, so re-forcing it is a no-op. Only the three known knob names are ever loaded or forced, so a stale or hand-edited rkp.json can never steer resetprop at an arbitrary property.

The toggle itself moved into the daemon. It used to shell out resetprop and write rkp.json from the WebUI, two out-of-process steps the daemon re-read on an unrelated schedule; a re-push landing between them could read the old file and force the old value back, undoing the toggle the user just made. A new POST /rkp sets the property live and persists the choice as one step under the same lock as the boot re-force (resolveAndPush), so the two can no longer interleave and every write to rkp.json serializes through the daemon. The live set now goes through the same resetprop -n path as the boot re-force; keystore2 reads the knob on demand when it provisions, so the value still takes effect without a property retrigger.

Closes #244.