Never leave a claimed slot marked and unsent

[jeffwall-curlewlabs]

A clock claims a slot's mark, reads the ledger, then sends. In v0.2.0, two paths can leave the mark in place with nothing sent. Every later tick then reads the slot as sent, and only GitHub's backstop delivers it, late. It's one slot per failure, since the next slot has a mark of its own.

1. The ledger read after the claim fails. It now releases the mark, the same way a failed send already did.

2. The claim's create lands, but GitHub answers otherwise. gh_api retries a POST whose answer was lost, so:

   • The retry is told the ref already exists, and the clock takes its own mark for another clock's.
   • If the lost answer was the last attempt's, the claim fails with the mark already in place.

   Each claim's note now carries a random id, so its blob is that claim's alone. A claim that is refused or fails reads the mark, and holds it when the mark points at its own blob.

What's still not covered: a clock that can neither create nor read the mark, or one stopped between its claim and its send. Either way GitHub's backstop delivers the slot late, as the README says.

Tests:

• Unit tests for a failed ledger read, which must release the mark so the next tick sends.
• Unit tests for each create outcome: a refused retry of its own create, a create that landed but failed, a create that never landed, and another claim's mark.
• The new tests fail against v0.2.0's code.
• The live check now claims the same mark twice with one id, which is what a retried create that landed looks like, and confirms the claim holds it. That depends on the note hashing to the blob GitHub created.

Run from a Mac against this repository: unit tests on Python 3.14 and 3.10, and the full live check with --require-clock-check.

The version goes to 0.2.1.