v0.37.11

A retried harness create no longer makes a second harness

POST /v1/harnesses now honours an Idempotency-Key, as a task already did. When a create reached the server but its answer was lost (a timeout, a dropped connection), the client could not tell whether the harness existed, and its retry made a second one. With a key, the retry gets the first harness back:

• A repeat of the key answers with the harness the first request created. If that request is still writing it, the repeat waits for it rather than answering not found.
• The same key with a different request is refused 409 idempotency_key_reused.
• Once the key's harness is deleted, the key names none, and a repeat creates one.
• A key belongs to the workspace the harness is made in and is kept for 24 hours. The server reports the harness_idempotency capability.

Deploy to Cloud sends a key on each create, made from the setup and the form it sends, so a deploy whose answer was lost no longer leaves a second copy in Cloud (the known issue since 0.36.3). It sends one only to a Cloud that reports the capability.

The protocol text is in Harnesses §5.1 of UHP 2026-10-19, an addition within the version, and conformance suite 2026.10.19.post4 checks it as F-10. Thanks to @Jahanzeb-git (#613, #582).

Full Changelog: v0.37.10...v0.37.11