fix(s024): a signer that signs again clears the signer alarm

References the red test in the previous commit: sign_if_needed/2 and sign_checkpoint/1 clear
the alarm on a successful signature when it is set, which Alarm's doc has promised since 024.

Signed-off-by: Ayla Croft <aylacroft@proton.me>

Author: HackTuah

coverage.tsv

@@ -15,3 +15,4 @@ slice_id	percent	sha	date
 030	78.40	c657da8	2026-09-21
 033	78.50	3b5e89e	2026-09-21
 034	78.83	3a5785f	2026-09-21
+032	79.01	732238c	2026-09-21

lib/trinity/receipts/chain_writer.ex

@@ -226,6 +226,9 @@ defmodule Trinity.Receipts.ChainWriter do
     if Receipt.signed?(kind) do
       case KeyCustody.sign(bytes) do
         {:ok, sig} ->
+          # fix(s024) at slice 032: a signer that signs again clears the alarm, as Alarm's
+          # doc has said since 024; before this nothing did.
+          if Trinity.Receipts.Alarm.set?(), do: Trinity.Receipts.Alarm.clear()
           {:ok, sig}
 
         {:error, reason} ->
@@ -322,6 +325,7 @@ defmodule Trinity.Receipts.ChainWriter do
   defp sign_checkpoint(bytes) do
     case KeyCustody.sign(bytes) do
       {:ok, signature} ->
+        if Trinity.Receipts.Alarm.set?(), do: Trinity.Receipts.Alarm.clear()
         {:ok, signature}
 
       {:error, why} ->

slices/032-semantic-memory/NOTES.md

@@ -191,6 +191,14 @@ produced each vector is recorded on the row (decision 4).
     On this machine: dim 384, 0.858, 0.062, three embeds in 281 ms. The owner's manual queue keeps AC2 all the
     same, on their machine.
 
+12. **An HNSW scan with a WHERE clause can come back short.** The postgres job (run 35604770525) answered two
+    of three rows for the smoke's vector check: pgvector's HNSW scan hands back its `ef_search` (40) nearest
+    index entries and the filter (persona, scope, model) is applied after; the index held other personas'
+    entries and dead tuples from rolled-back inserts, so a small persona's rows fell outside the candidates.
+    Reproduced locally one run in three; closed by `SET LOCAL hnsw.iterative_scan = strict_order` inside the
+    search's own transaction (pgvector 0.8, `fix(s032)` de55660), which walks on until the LIMIT is met with the
+    order exact. Four runs of the three memory files on the container after: 21 passed each.
+
 ## Follow-ups
 
 - **A local embedding backend for the Linux bundle and for Windows.** The Linux bundle boots with the tier