layout editor: column drag follows the pointer through the cell floor

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/claude/invariants-plot-and-layout.md

@@ -138,9 +138,17 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   - **Widths are weights with a floor.** The plotter keeps 64 px logical per cell and a column gap
     (`kColGap`, 6 px); the editor's drag is stricter (below). A weight is a share of what is
     left *after* the floors, so cells of `{3, 1}` read 533:220 in a 756 px figure, not 3:1, and the
-    editor's 96 px drag floor is a floor on the *share it asks for*: a cell dragged to the limit realises
-    `64 + share * remainder` and reads wider (144 px in the split probe's `pre-insert0` line), so the
-    boundary does not follow the pointer one for one near either extreme.
+    editor's 96 px drag floor is a floor on the *width*, not on the share. Because a cell's width is
+    `64 + extra * weight / total` and not proportional to its weight, `layout_col_apply()` does not scale
+    the pair's weights by the width ratio: it keeps the pair's weight sum `S` from the drag's *start*
+    (`layout_col_drag_start`) and gives the left cell `S * (want_left - 64) / (pair - 128)`, clamped to
+    `[0.001, 0.999]` (the plotter refuses non-positive weights; `0.5` if the pair is not wider than 128).
+    `want_left` is the pointer's width clamped to `[96, pair - 96]` logical px. The divider therefore
+    follows the pointer, the shrinking cell reads 96 px at the extreme and the pair keeps its total width
+    (the split probe's `col-drag` line asserts all three). `kPlotterMinCellPx` (64) mirrors the plotter's
+    `kMinCellWidthLogical`; both are logical px (the plotter scales it by `ui_scale`, which is
+    `PlotArea::device_scale()`, the divisor used to turn layout rects into logical px), so the two
+    must change together.
   - **A cell is removed with its traces, and a new cell is empty.** `insert_cell(fr, at)` pushes the
     cells at and after `at` right *with their contents* (the same rule as `insert_row()`), and
     `remove_cell(plot)` on a one-cell row removes the row. Both return false at a cap or when they would

docs/claude/probe-readings.md

@@ -2892,8 +2892,8 @@ The other lines, in order:
 | `invalid-rows` | `ok=1 frows/plots=[5/5 3/3 3/3 3/3]` | one of four unusable `row` sequences (five cells in a row; a skipped row; a row that goes back; a first row that is not 0) that was refused, or kept as a split instead of loading one cell per row |
 | `editor-on` -> `cell-split` | `cells=[1]` then `cell-split-ck cells=2` and `cell-split` with `widths=[376,376]`, the new `1b` empty | the editor's cell `+` not reaching `insert_cell()`, or the figure not re-pointed after it |
 | `cell-assigned` | `1a:sine\|1b:square` | an assignment into the new cell that landed on another plot |
-| `col-drag` | `left_gt=1 both_above_min=1 left_gt_right=1 tile=1`; `pair_sum` constant (753 at the 756 px window) | the column drag not moving the boundary (`left_gt=0`), a cell dragged below `kMinCellPx` (`both_above_min=0`), or a drag that changes the pair's total instead of redistributing it. The probe applies +80 px, then +/-10000 px through `layout_col_apply()` |
-| `pre-insert0` (state line) | after the extreme drags `widths=[144,609]` | not a defect: the drag floors the left share at 96 px of the pair, but the plotter realises `64 + share * remainder`, so a cell dragged to the limit reads wider than 96 (see [invariants-plot-and-layout.md](invariants-plot-and-layout.md)) |
+| `col-drag` | `ok=1 left_gt_right=1 follows_80=1 relative=1 sum_80=1 right_floor=1 left_floor=1 sum_ext=1 both_above_min=1 tile=1`, then `d80=[376.5,376.5]->[456.5,296.5]` and `ext=[657.0,96.0\|96.0,657.0]` (all logical px, 753 px pair) | `ok` is the AND of the checks. `follows_80=0`: the drag of +80 did not put the left cell within 1 px of `start + 80` (the weights were taken as proportional to widths and the plotter's 64 px floor ignored -- an old reading was `[442.9,310.1]`); `relative=0`: three updates (+30, +60, +80) from one begin did not land at +80, i.e. the drag read the live weights instead of the begin snapshot `layout_col_drag_start`; `sum_80=0` / `sum_ext=0`: the pair's total changed instead of being redistributed; `right_floor=0` / `left_floor=0`: after +10000 / -10000 the shrinking cell does not read `kMinCellPx` (96) within 1 px; `both_above_min=0`: a cell below 96 px; `tile=1` is `split_probe_tile()`, the same check the state lines print. `left_gt_right` is `d80.l > d80.r` (after +80 from equal halves the left is the wider). The probe goes through `layout_col_drag_begin()` + `layout_col_apply()`, the pair the gesture calls |
+| `pre-insert0` (state line) | after the extreme drags `widths=[96,657]` | the last extreme drag was -10000: the left cell sits on the 96 px floor and the right takes the rest of the pair. A left cell reading 144 is the old floor-ignoring weights (`weights=[0.25,1.75]`); correct weights read `[0.1,1.9]` |
 | `insert0-move` | `move_ok=1 before=[sine,square] after=[,sine,square]` | an insert at the left edge that renumbered the cells instead of moving their traces right with them |
 | `remove-mid` | `rm_ok=1 after=[,square]` | removing a middle cell that dropped or shifted the wrong neighbour |
 | `row-weights` | `wt_ok=1 before=[3,1,1] after=[1,1]` | the row weights not following an insert or removal of a *figure row* (the vector had the plot-count length once and drifted off the rows) |