The Grids guide does not say what a commit into a sorted column does

Context

Leaf of #18762 (public proof). Measured at user level on examples/grid/cellEditing (Playwright e2e rig, dev@0e3fb712ff), header clicks and keys only.

The Problem

A commit into the sorted column moves nothing: the row stays where the user edited it, and the order is restored by the next sort. The same holds for a filter (measured on the pooled fixture: a committed value that no longer matches the active filter stays visible; Enter and Tab stay clean). Neither the guide nor any arm says so — a reader cannot tell a contract from an accident, and a store change that re-sorts on a record change would break Tab's walk with no arm noticing.

The Architectural Reality

• src/data/Store.mjs#onRecordChange (:1330) fires recordChange and nothing else; collection.Base#autoSort sorts "when adding / inserting" and when the sorters change (:170, :256).
• CellEditing#getAdjacentEditableCell already documents the premise from its side: "A logical target — record and dataField — so a commit that re-sorts the store cannot move it."

The Decision This Ticket Records

The row stays put. An edit that teleports its row out from under the user — mid Tab-walk, with the next cell's editor opening somewhere else — is the worse default for a grid that is being edited, and the next sort or filter change restores the order. The alternative (re-sort and re-filter when an edit ends) is a store-wide behaviour change with its own consumers; it is out of scope here and needs its own ticket if wanted.

The Fix

• learn/guides/datahandling/Grids.md, "What Scrolling Does to an Edit": one passage — a commit into the sorted column moves no row; sorters apply when THEY change. The filter half stays out of the guide: it was measured on the pooled fixture, and the public example offers no filter an arm could drive, so the guide would carry a claim without an arm.
• One arm in test/playwright/e2e/grid/CellEditingExample.spec.mjs: sort by the header, commit a value that belongs at the other end, the row keeps its place and Tab's next cell is in the same row; the next header click sorts it away.

Acceptance Criteria

• The guide states that a commit into the sorted column moves no row, and when the order is restored.
• An arm on the public example pins it: after the commit the edited row keeps its position, and the next header click re-sorts it.
• The claim maps to the arm (the guide's claim → arm discipline).

Out of Scope

• Re-sorting or re-filtering when an edit ends.
• The header's sort indicator over data an edit has unsorted.

Related

#18762 (epic) · #18866 (the guide's cell-editing contract) · #18941 (where the store behaviour was first measured)

Live latest-open sweep: checked latest 20 open issues at 2026-09-19T13:24:16Z; no equivalent found. A2A claim sweep: latest 6 messages (all read-states) at 13:24Z; no overlapping claim. MC sweep: "store does not re-sort or re-filter when a record field changes, edited row stays in place in a sorted grid column, autoSort", 4 results (2026-02/03 DevIndex sorter and rank sessions); no decision on re-sorting at a record change. Own-assignment sweep: 2 open (#15252, #18950), not overlapping.

Origin Session ID: 2c9503fc-beef-4d80-939b-7d616601cd97 Retrieval Hint: "commit into sorted column row stays put store recordChange no re-sort guide arm"