Module breakpoint 

Breakpoints — where the operator asked execution to stop.

Why this is not a Finding

Everything else escriba paints in the gutter is a finding, and reusing that plane was the obvious move. It is also wrong, twice over, and both failures are silent:

• Every escriba_shirube list is ANCHORED, and the gutter’s only reader flat-maps ResultList::fresh(world). That is exactly right for a diagnostic — a marker computed against text the operator has since edited is confidently wrong — and exactly wrong for a breakpoint, which would vanish on the next keystroke.
• ListRegistry::publish replaces a list wholesale and FOCUSES it, so ]d would start walking breakpoints as though they were problems.

A finding is something a PRODUCER found and is only as good as the world it was computed in. A breakpoint is something the OPERATOR put there, and it is as good as their intention, which no edit invalidates.

What this does NOT do yet, stated plainly

A breakpoint is keyed by (buffer, line number) and does not shift when text above it is edited. Insert a line at the top of the file and the breakpoint stays on the line NUMBER it was set on, not on the line of code it was set against. Nothing in escriba shifts a mark under an edit today — findings dodge the problem by dying, which is the option a breakpoint does not have — so this is the honest floor rather than a bug that slipped through: the operator’s breakpoint survives their typing, which is the property that matters most, and it can drift.

Shifting under an edit is the next piece, and it is a shared primitive rather than a patch here: the same machinery would fix findings, marks (m[a-z]), and the jumplist. Do not paper over it with an ad-hoc adjustment in this file.

Structs

Breakpoints

Every line the operator has marked for the debugger to stop on.