Queue the slice-from-ptr message, which names a range nobody wrote

NEXT.md

@@ -8,6 +8,26 @@ and the author's words are that they feel like extra language features. `any` is
 tagged union (two words, a pointer and a typeid, no GC). `drop` is `spec-memory.md`'s hook for owning
 something that is not memory. Their old entries stand; do not schedule either.
 
+## Queued: `slice-from-ptr`'s run-time refusal names a range the caller never wrote
+
+Small, and known rough at the time it shipped. `(slice-from-ptr p n)` with a **computed** negative
+length is caught at run time — the check is `icmp sge i64 n, 0`, signed, because `check_slice`'s own
+comparisons are unsigned and a negative `i32` sign-extended to `i64` becomes a huge `u64` that passes
+both clauses. The catch is right. The message is not:
+
+```
+slice [0 -2) is out of bounds for length 0
+```
+
+It reuses `@flan_slice_error`, so it reports a range and a length the caller never wrote. The
+condition actually violated is `0 <= n`, which is the same *shape* as a reversed range, and that is
+why the existing function accepted it — but `slice-from-ptr` is the one form in the language where the
+compiler cannot check the thing that matters, so its refusal is the place the promise should be
+spelled out and it is the one place it is not.
+
+The fix is a function in `runtime/` — that directory was held by another lane when this landed, which
+is the whole reason it was left. Say what the caller promised and what was passed.
+
 ## The backend, in the order that finishes it
 
 `DISCUSS.md` item 16 is the report and its verdict is the sequencing: *"the wiring is done and it was