fix(cassettes): break the same-second tie with the machine's counter

The ordering gate compares created_at, which NIP-01 defines at one-second
granularity. A dispense and the publish that follows it land inside one
second routinely, so the report was dropped and the operator kept the
pre-dispense count until the next heartbeat five minutes later.

The machine bumps a counter on every local change to a bay count and
carries it in its state document. m015 stores it per row, and the gate
consults it only when the stamps are equal, where created_at carries no
information at all.

Only on equality, deliberately. A machine whose state.db was replaced
restarts its counter at zero while its wall clock keeps moving forward;
gating on the counter across different stamps would lock that machine out
for good. Equal stamps with no counter on either side stay closed, which
costs one heartbeat and risks nothing.

migrations.py

@@ -922,3 +922,22 @@ async def m014_add_counts_uncertain_since(db):
         "ALTER TABLE spirekeeper.dca_machines "
         "ADD COLUMN counts_uncertain_since TIMESTAMP"
     )
+
+
+async def m015_add_cassette_state_seq(db):
+    """Break the same-second tie in the state-event ordering gate.
+
+    The gate compares `created_at`, which NIP-01 defines at one-second
+    granularity — so two reports from the same second are indistinguishable to
+    it, and the later one is dropped. A dispense and the publish that follows
+    it land inside one second routinely.
+
+    The machine bumps `seq` on every local change to a bay count, whatever
+    caused it, and carries it in the state document. Stored per row alongside
+    `state_at` and consulted ONLY when the stamps are equal, so a machine whose
+    state.db was replaced — seq back to zero, wall clock still moving forward —
+    is not locked out by its own counter.
+    """
+    await db.execute(
+        "ALTER TABLE spirekeeper.cassette_configs ADD COLUMN state_seq INTEGER"
+    )