Delete control-start-refused: both platforms report a refused start now

phyphox-android 44678d6d and phyphox-ios 37af4187 both landed on
development, and iOS covered it with tests. Once every implementation
agrees the entry goes, together with its spec references - readers learn
about corrected behaviour from the release changelog, not from a lingering
note.

What stays is the contract itself: openapi.yaml documents that the result
of cmd=start reflects whether the measurement actually began, which is now
what both apps do. Both platform TODO files are deleted; the item was
their only content.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: Staacks

docs/remote-interface/openapi.yaml

@@ -260,7 +260,6 @@ paths:
       tags: [control]
       summary: Start, stop, clear, or write a value
       operationId: control
-      x-phyphox-inconsistency: [control-start-refused]
       description: |
         Sends a command to the running experiment. Always answers with
         `{"result": true}` or `{"result": false}`; the response says whether the
@@ -333,7 +332,6 @@ paths:
       tags: [control]
       summary: Start, stop, clear, or write a value (POST)
       operationId: controlPost
-      x-phyphox-inconsistency: [control-start-refused]
       description: |
         Identical to `GET /control`, with the command and its parameters in the
         request body, e.g. `{"cmd": "set", "buffer": "height", "value": 1.87}`.

inconsistencies.yml

@@ -89,35 +89,3 @@
     A non-power-of-two number of input samples yields a different output
     length and different values on the two platforms; a power-of-two input
     gives identical results on both.
-
-- id: control-start-refused
-  title: 'A refused start still answers {"result": true}'
-  area: remote-interface
-  status: decided
-  canonical: >-
-    `/control?cmd=start` must answer `{"result": false}` when the experiment
-    was not started. Whether a start succeeds is not something a remote client
-    can otherwise determine: the only other signal is `status.measuring` in a
-    subsequent `/get`, which requires a second request and a race-free moment
-    to make it in.
-  affects:
-    android: >-
-      Answers `{"result": true}` for a start the app refused. Observed on a
-      Pixel 3 with a Bluetooth experiment whose device was not yet fully
-      connected: the app put "The Bluetooth device is not connected. Experiment
-      can not be started." on screen, `status.measuring` stayed false, and
-      `/control?cmd=start` reported success.
-  verified: >-
-    2026-08-27, Android development build on a Pixel 3 against an ESP32 running
-    the Arduino randomNumbers example (phyphox-docs device lab, ble suite).
-  summary: >-
-    A client that starts an experiment over the remote interface cannot tell
-    from the answer whether it is running. The documented meaning of `result`
-    is "whether the command was accepted", and Android still answers that
-    literally - a start that the app then refuses, because a Bluetooth device
-    is not connected or another precondition fails, is still reported as
-    successful. The maintainer decided (2026-08-28) that the result must
-    reflect whether the measurement actually started; iOS was corrected on its
-    development branch the same day and now answers `false` for a refused
-    start. Until Android follows, poll `status.measuring` from `/get` to
-    confirm a start rather than trusting the answer.