The arithmetic condition landed without restarts, and why that is a question

NEXT.md

@@ -1,3 +1,21 @@
+# Overnight, 2026-09-13 into 09-14 — one decision waiting for you
+
+**`ArithError` landed, but without the restarts you asked for.** The design agreed at the keyboard was
+a condition plus `use-value` everywhere and `saturate` where clamping is meaningful. What landed is the
+condition and the guards; no restart is established. The reason given is mechanical rather than a matter
+of taste, and it is worth your reading of it: `runtime/flan_rt.c:70-86` allocates a restart frame **in the
+`restart-case` that offers it, on that frame's own stack**, so the runtime cannot push one on a program's
+behalf. Offering `use-value` at a division would mean an alloca plus a push and pop emitted at every
+division in every checked build — which is the identical cost `lib/prelude.ml:70-76` already refuses, in
+prose and on the record, for indexing. `HANDOFF-arith.md` is the full write-up.
+
+So the question back to you: **is signal-and-die-with-a-location enough for arithmetic, the way it is for
+`BoundsError`, or do you want `saturate` on the cast arm** — which is the one case where clamping is
+canonical rather than arbitrary, and where casts are rare enough that the cost does not matter? That
+follow-up is named in the handoff and not built. Nothing else about the feature is in question: both
+backends agree byte for byte on all ten cases, and float division is deliberately unguarded because
+IEEE already answers it.
+
 # Where this is — end of 2026-09-13, second handoff
 
 **Branch `dev-loop` at `e725a5a`, working tree clean, `dune test` green, every lane merged.**