@lotics/ui 26.4.1 → 27.7.0

package/MIGRATION.md

@@ -4,6 +4,76 @@ Breaking changes, newest first — normally per major, plus the rare minor that
 anyway (recorded under its exact version). The current contract lives in `AGENTS.md` + `docs/`;
 this file exists only to move an app from one release to the next.
 
+## 27.4.0 — a `Select` trigger announces as `combobox`, not `button`
+
+No API change, but the DOM and the accessibility tree changed, so **a test or script that
+finds a Select by its button role must be updated**:
+
+```ts
+getByRole("button", { name: "Tags" })    // BEFORE — a <button> element
+getByRole("combobox", { name: "Tags" })  // AFTER  — a <div role="combobox">
+```
+
+The trigger had to stop being a `<button>` element: the sanctioned chip box
+(`renderSelected` → `<Chip onDismiss>`) puts a remove button inside the trigger, and
+`<button>`'s content model forbids interactive descendants — so every multi Select with
+chips rendered invalid HTML and threw a React error on mount. `combobox` is also the role
+the APG pattern this control already follows calls for. Focus, Enter/Space, pointer open,
+Escape, and chip removal are unchanged.
+
+Note for `searchable`: `OptionList`'s filter input is a combobox too, so scope such a query
+to the trigger (or use `.first()`) rather than assuming one match per Select.
+
+## 27.2.0 — a `LedgerGroup`'s sum moved below its rows
+
+No API change; the rendering moved. A summed group used to print `LABEL … sum` as an eyebrow
+ABOVE its rows and now closes them: the rows come first, then `Label   sum` at `sm/medium`,
+with no eyebrow (the label travels with the sum instead of being said twice).
+
+**If you mix summed and unsummed groups in one `Ledger`, that now looks inconsistent** — an
+unsummed group still captions from above, so the group names land in two different places.
+This is the one case that wants an edit: give every group a `total`, and let a lone row stand
+bare rather than grouping it (a one-row group's sum only restates the row). Omitting `total`
+remains fully supported for a statement whose groups all name categories without summing them.
+
+## 27.0.0 — `TextButton` is REMOVED; an act carries a control surface
+
+**`@lotics/ui/text_button` is gone, with no replacement component.** It was the wrong
+abstraction, and 25.0.0 had already retreated from it inside `ReferenceField`.
+
+It existed to solve one real problem: a fill-less `Button`'s optical edge is its INK, inset by its
+padding, so it reads as indented against a column of labels. But paying for that with a third rung
+cost more than it bought — **underline came to mean two things at once**, separable only by ink
+(blue navigates, zinc acts), so the affordance stopped answering the only question a reader has:
+does this take me away, or does it do something here. And it duplicated the `Button` colour ladder,
+where `muted` already IS the quiet rung.
+
+**The new law: an ACT carries a control surface; only NAVIGATION is underlined text.** Chrome has
+two rungs — `Button` (40px, a surface) and `InlineButton` (28px, filled, on a field's own surface).
+`Link`/`TextLink` stay underlined and go somewhere.
+
+```tsx
+<TextButton onPress={selectAll}>Select all</TextButton>            // BEFORE
+<Button title="Select all" color="muted" onPress={selectAll} />    // AFTER
+
+<TextButton color="danger" onPress={del}>Remove fee</TextButton>   // BEFORE
+<Button title="Remove fee" color="danger" onPress={del} />         // AFTER — rule 9's convention
+```
+
+**Per call site, pick by WHERE the act sits, not by how quiet you want it to look:**
+
+- In **chrome** — a `PopoverFooter`, a heading row, a select-all band — use `Button color="muted"`.
+  Nothing there establishes a text edge, so the padding inset costs nothing. (`FilterChip`'s Clear
+  and `OptionList`'s select-all/deselect-all moved this way inside the kit.)
+- **Destructive** — `Button color="danger"`, bottom-left after the entity's fields, per composition
+  rule 9. That is the page-wide convention a text-weight verb was quietly opting out of.
+- **An add** — `Button` below the list it extends, per rule 8.
+- Still tempted to align a quiet verb to a column of TEXT? **Move the act, don't restyle it.** That
+  pull is what produced the rung in the first place.
+
+`TextLink` is unchanged. Its `onPress`-free forms — an `href` link, or a passive underlined marker
+on a value whose press opens a peek — were never this component's job and keep working.
+
 ## 26.0.0 — a section's ADD moves to its heading row; `EmptyState` loses its verb
 
 **`EmptyState.action` is REMOVED — no replacement on that component.** Two different things

package/docs/catalog.md

@@ -467,8 +467,9 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
 
 - **`button`** — `Button`: the labelled action; `title` MANDATORY (it is the accessible
   name), `color` = emphasis/risk. A fill-less `Button` shows no box, so its optical
-  edge is its INK, inset by its padding — don't align one to a column of TEXT; that
-  is `TextButton`'s job.
+  edge is its INK, inset by its padding — don't align one to a column of TEXT. There is
+  no text-weight rung to reach for: move the act into chrome (a `PopoverFooter`, a
+  heading row) where no text edge exists to betray, or give it the filled tier.
 - **`icon_button`** — `IconButton`: the icon-only circular action (see
   [Actions](#actions)).
 - **`back_button`** — `BackButton`: the one go-back control — don't hand-roll it (an
@@ -485,18 +486,8 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   with no `href` it stays NEUTRAL: plain underlined text to wrap in your own pressable,
   or a MARKER that a value leads somewhere (a record reference whose press opens a peek,
   not a trip). `color` overrides either way; inherits every `Text` prop. It does NOT
-  act — that's `TextButton`.
-- **`text_button`** — `TextButton`: a low-chrome ACTION at text weight ("Select all",
-  "Clear", "Add stop") — the third rung of chrome after `Button` (40px surface) and
-  `InlineButton` (28px, filled, on a field's surface). **Underlined, in neutral ink**:
-  underline marks interactive, blue marks navigation — so `Link` goes somewhere and
-  this acts. Choose by what the press DOES. The underline is not optional (position is
-  a learned convention, hover is absent on touch). `TextButtonColor` is
-  `default | danger` only — `muted` would mute the thing carrying the act (use
-  `Button color="muted"`). `onPress` REQUIRED; `disabled` greys to zinc-400, drops the
-  press + wash, announces `aria-disabled`. Hover wash, focus ring and a 40px target
-  (32px box + `hitSlop`) come from `PressableHighlight` — a pressable `Text` has
-  none of them. ONE size, no icon (a verb needing a glyph is a `Button`).
+  act: an act carries a control surface (`Button`/`InlineButton`), and underlined text
+  is the NAVIGATION affordance only.
 - **`chip`** — `Chip`: the generic pill — pressable when `onPress` (announces as a button;
   pass `accessibilityLabel` when children aren't self-describing text) + an
   absolutely-positioned dismiss ✕ sibling when `onDismiss` (its name = `dismissTooltip` ??
@@ -588,7 +579,14 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   also home of the shared `PickerOption` type.
 - **`select`** — `Select`: rich/custom-rendered, single/multi, select-all, chips via
   `renderSelected(item, { remove })` + `searchable` + `allowCustom` — the tag field is just
-  a multi Select; opens `OptionList`.
+  a multi Select; opens `OptionList`. Its trigger is `role="combobox"` (a `<div>`), never
+  `role="button"`: the chip box legitimately puts a remove button INSIDE the trigger, and a
+  real `<button>` may not contain one. **Any trigger that renders caller-supplied content
+  must not take `accessibilityRole="button"`** — react-native-web picks the element from the
+  role, and `<button>`'s content model forbids interactive descendants, so the first caller
+  to pass a chip, link, or menu makes the markup invalid. Either take a non-button role, or
+  keep the verbs OUTSIDE the pressable as siblings (`Chip`'s absolute ✕, `InlineEditView`'s
+  shell-owned `actions`).
 - **`option_list`** — `OptionList`: the ONE shared searchable listbox body every selector
   opens — single/multi, optional internal search, create row, keyboard + native-`<select>`
   typeahead; host it directly in a `Popover`/`Dialog` for a command palette.
@@ -838,18 +836,54 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   `metric` {label,value,tone,note} pinned right, the band's ONE accent. The record's FIELDS
   never live in the header: compose them as `DetailTable`s in the sections below. Replaces
   hand-rolled record headers (mixed scales, several competing figures, color noise).
-- **`ledger`** — `Ledger` + `LedgerGroup` + `LedgerRow` + `LedgerTotal` — the record-level
-  money list: charge/receipt GROUPS with sums in their headers, every figure on ONE
-  right-aligned tabular column, `peek` turns a row into a pressable door floating its
-  particulars in an anchored popover (put links INSIDE the peek — never a button in a
-  button; `reference` is the trailing-link alternative for static rows), `LedgerTotal` = the
-  divider-set emphasized close with `zeroLabel` for settled. The financial-statement grammar
-  at record density; worked example: [`tpl_item_list`](../examples/tpl_item_list.tsx)
-  drawer.
+- **`ledger`** — `Ledger` + `LedgerGroup` + `LedgerBasis` + `LedgerRow` + `LedgerTotal` — the
+  record-level money list: every figure on ONE right-aligned tabular column, `peek` turns a row
+  into a pressable door floating its particulars in an anchored popover (put links INSIDE the
+  peek — never a button in a button; `reference` is the trailing-link alternative for static
+  rows), `LedgerTotal` = the divider-set emphasized close with `zeroLabel` for settled. **`meta` is a
+  neutral QUALIFIER** (a date, a method) at caption weight — never a problem or a state: one
+  row's meta being a fact and another's a complaint is what makes a column read inconsistent,
+  and a caption is the wrong weight for something wanting action. A problem goes on the row
+  that can FIX it, and in a statement the arithmetic has usually said it already.
+  **Pick the shape by what the statement IS**, because there are two and they read differently:
+  - **`charges → total`** — `LedgerGroup`s, each **closed by its own sum** ("Charges" vs
+    "Received"), giving three ascending rungs: row `sm/regular`, subtotal `sm/medium`, total
+    `md/semibold` over its rule. A summed group's label travels WITH its sum and takes no
+    eyebrow, so its rows are met before its name and must carry the side themselves, by opposite
+    SIGNS. Two same-signed groups are two statements, not two sides; give them two `Ledger`s.
+    A `total` must equal the rows it closes — derive the rows and the sum from ONE list, never
+    from two predicates that can drift apart — and it earns its place only by adding what the
+    rows don't already say, which a one-row group's sum doesn't. **Omitting `total` is a shape,
+    not a degradation**: the label becomes a caption ABOVE the rows, for a group that names a
+    category rather than summing a side. **Don't mix the two in one `Ledger`** — the label would
+    sit above some groups and below others, reading as an accident; if any group earns a sum,
+    give every group one and let a lone row stand bare instead of grouping it.
+  - **`basis → derived → total`** — duty off a customs value, commission off gross, interest
+    off principal. The base is **`LedgerBasis`** (label + value + optional `meta` for how it was
+    arrived at), which takes the third treatment on the money column and sets its `Divider`
+    BELOW it, since a premise separates itself from what it feeds. Do not render a base as a
+    `LedgerRow` — that claims it is a peer you could add to the rows under it — and do not wrap
+    it in a one-row group. With one side there is no group at all: the levies are bare
+    `LedgerRow`s between the basis and the total.
+  Worked example: [`tpl_record`](../examples/tpl_record.tsx) § Billing — a three-sided closing
+  statement (billed, less credited, less received) exercising every row state: a `peek` door
+  whose lookup link sits INSIDE the popover, a flat `reference` on the row with nothing to
+  expand, `meta` + `success` tone on money coming back, and a one-row `Adjustments` group that
+  takes no `total`. `Received` is derived from the charges carrying a payment METHOD rather than
+  a second flag to keep in step, and the refundable deposit stays OUT because a ledger earns
+  trust by summing exactly what its label claims. `LedgerBasis` is demoed on the gallery's
+  Charts page instead — a delivery order has no base to compute from, and inventing one to
+  place a component is how invented needs start.
 - **`reference_field`** — `ReferenceField`: a reference to ANOTHER RECORD, rendered as a
   FIELD VALUE — the kit's inline-editor surface (so a pointer sits in the value column
   like the editors above and below it), whose press opens a PEEK of that record's facts.
-  `name` + optional `code` + `facts`, plus the verb callbacks below. The verbs live INSIDE the
+  `name` + optional `code` + `facts`, plus the verb callbacks below. The peek takes THE FIELD'S
+  WIDTH (`inheritTriggerWidth`, as `InlineSelect` does), floored at `MIN_CONTROL_WIDTH` — a
+  panel narrower than the control that opened it reads as belonging to something else. So the
+  field truncates its name to one line and the peek's header WRAPS the whole of it: the column
+  stays scannable, the full value is one press away. Between the floor and `labelWidth +
+  MIN_CONTROL_WIDTH + 24` a `DetailTable` stacks, which is the right grammar at that width.
+  The verbs live INSIDE the
   peek, never on the field, and they are ALL `Button`s at one altitude — a peek is
   dialog-scale and a dialog's verbs are buttons, so mixing weights only made the reader rank
   four acts that are four acts. The row splits by WHAT EACH TOUCHES, and the spacer is that
@@ -948,7 +982,12 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
 - **`filter_chip`** — `FilterChip` + `selectSummary`: the toolbar filter pill hosting a
   facet (options, a `Slider range`, a `Counter`).
 - **`summary_line`** — `SummaryLine`: the light inline summary of a register/list's FILTERED
-  view, sits below the toolbar; NOT the boxed dashboard `kpi_strip` band.
+  view, sits below the toolbar; NOT the boxed dashboard `kpi_strip` band. Every item is an
+  AGGREGATE over the rows in view (a count, a sum, a fill), and the strip goes with the set it
+  summarizes — including a record's child list (a consol's houses, an order's lines). **Never on
+  a record's identity band reporting that record's own state**: derived verdicts on one record
+  ("documents incomplete", "2 fields need checking") are the checklist a record must not carry
+  (§`pipeline`) and restate at a distance what the sections below state in place.
 - **`use_selection`** — `useSelection`: always-on multi-select state for a register/list —
   the `selected` Set + `toggle`/`setAll`/`allSelected`/`indeterminate`/`count`/`clear`;
   selectability gating stays with the caller. The checkbox-always-visible counterpart to

package/docs/composition.md

@@ -471,17 +471,19 @@ All view controls are 40px tall (`CONTROL_HEIGHT`), `sm` labels, in ONE wrapping
   `danger` (and its quieter `danger-secondary`) marks destructive — that's the whole axis. A
   fill-less `Button` (`danger-secondary`, `muted`, un-colored) shows no box, so its optical edge is
   its INK, inset by its padding: **never align one to a column of TEXT** — it reads as indented
-  against every label starting on the true edge, and reaching for the filled tier to fix that buys
-  alignment with prominence, on what is usually the rarest act on the surface. A text-weight act is
-  `TextButton`, which lands its ink on the column by construction. Chrome has three rungs: `Button` (a 40px control with a
-  surface) → `InlineButton` (28px, filled, on a field's own surface) → `TextButton` (no surface,
-  sitting in a line of text). **UNDERLINE MARKS INTERACTIVE, BLUE MARKS NAVIGATION** — so
-  `Link`/`TextLink` are blue + underline and GO somewhere, `TextButton` is zinc + underline and
-  ACTS. Pick by what the press DOES. The underline is not optional on a surface-less control:
-  POSITION is a learned convention rather than an affordance (invisible to a first-time reader) and
-  hover is not one either (absent on touch, revealed only once you're already there). A tint is the
-  other way to say it — the Material/HIG answer — but blue is spoken for here and a second accent
-  for "actionable" would collide with one-accent-per-purpose. Never a `muted` text action: it mutes
+  against every label starting on the true edge. The answer is to move the act, not to invent a
+  rung for it: a quiet verb belongs in CHROME (a `PopoverFooter`, a heading row, a select-all
+  band) where nothing establishes a text edge to betray, and a destructive one belongs where rule 9
+  already puts it. Chrome has TWO rungs: `Button` (a 40px control with a surface) →
+  `InlineButton` (28px, filled, on a field's own surface).
+
+  **AN ACT CARRIES A CONTROL; ONLY NAVIGATION IS UNDERLINED TEXT.** `Link`/`TextLink` are the
+  underlined pair and they GO somewhere; everything that acts is a `Button` or an `InlineButton`.
+  A surface-less ACT was tried as a third rung and removed: it made underline mean two things at
+  once, separable only by ink, so the affordance stopped answering the one question a reader has —
+  does this take me away, or does it do something here. It also competed with the `Button` colour
+  ladder for the same job, since `muted` already IS the quiet rung. Pick by what the press DOES,
+  and let the surface say which kind it is. Never a `muted` text action: it mutes
   the one thing carrying the act. No
   "success"/green button. Decision UIs put positive/negative color on the STATUS (dot) and verdict
   (colored `Text`), not the buttons.
@@ -711,10 +713,10 @@ selection washes).
 (rose vs orange) stays on `Badge`s.
 
 Links use `Link`/`TextLink` (blue-600), never `solid("blue")` — and blue-600 means NAVIGATION
-specifically, not "interactive" generally: the underline is what marks a surface-less control
-interactive (see the button ladder above), so a `TextButton` ACTS and stays zinc. `TextLink` takes
-the blue only when it has an `href`; as a passive marker on a value it stays neutral, because a
-press that opens a PEEK is not a trip.
+specifically, not "interactive" generally. Underlined text is the NAVIGATION affordance and nothing
+else (see the button ladder above): an act carries a control surface. `TextLink` takes the blue only
+when it has an `href`; as a passive marker on a value it stays neutral, because a press that opens a
+PEEK is not a trip.
 
 ## `Badge` is for STATUS only — everything else is text
 

package/docs/templates.md

@@ -42,8 +42,7 @@ the package index is [../AGENTS.md](../AGENTS.md).
 | A guided sequence of physical tasks (scan, confirm, next) | `tpl_pick` |
 | Splitting one source amount across many targets | `tpl_allocate` |
 | A record's create/edit surface — also the settings shape | `tpl_record` |
-| A checklist ON a record (the canonical task-list grammar) | `tpl_item_list` (its Tasks section) |
-| A team task board (inline-managed grouped table) | `tpl_task_board` |
+| A surface whose SUBJECT is tasks (the canonical task-list grammar) | `tpl_task_board` |
 | One record HANDED between desks — stages that each own their controls | `tpl_record` (its Progress section) |
 | Financial statements | `tpl_statements` |
 | A scoped lookup report with export | `tpl_report` |
@@ -336,25 +335,36 @@ billing, and quick-capture templates. Top → bottom:
   `DrawerFooter`. "Add fee" rides the section heading's right edge — the one place it does not
   move as rows arrive — and is create-then-refine: a blank fee opens straight in the drawer. The
   empty state carries no button of its own, because that one is already on screen.
-- **Billing — a REGISTER, the same shape as Fees.** Both sections are a list of money items
-  where each item has detail and a per-item act, so both are a compact `Table` whose row opens
-  its FULL detail in a right-docked `Drawer` (◀ ▶ step the invoices) — the drill-down law.
-  It was three inline bands stacked, each with its own charge table, callout and action row,
-  plus two more bands after them: five subsections and four primaries in one section, which is
-  what made the area read as spread. A row now carries title, lines, total, a DERIVED state
-  `Badge`, the issued ref; the charge editors (ghost list prices with one-tap "Standard …"
-  fill, "How paid…" selects) live in the drawer with the lines they bill, and the section ends
-  with ONE summary (`SummaryLine`: to collect, deposit, issued) and ONE action row.
+- **Billing — INLINE bands, closed by a STATEMENT.** Each invoice is a `Subsection` costing ONE
+  line of chrome (its name, its total, its issued ref) over its charge rows in a `DetailTable`;
+  the charge editors carry ghost list prices with a one-tap "Standard …" fill and a "How paid…"
+  select. Three shapes were tried. Inline bands with a heading rung, a band callout and an
+  action row each made the CHROME three times the content; a `Table` + right-docked `Drawer`
+  then hid four charge lines behind three expansions, which trades a real fault for a worse one
+  — you can no longer see what you are paying for. So the lines all stay and the chrome
+  shrank, and a per-invoice problem rides the CHARGE ROW that has it (`warning` on the line
+  missing its method), which is smaller than a callout and more precise: it names the offender
+  instead of counting offenders.
+  The section then CLOSES with a `Ledger` — the money grammar's worked example, and the answer
+  the bands cannot give: three invoice totals down the page are three facts the reader has to
+  add up, and "is anything still owed" appeared nowhere. THREE sides — `Invoiced`, a one-row
+  `Adjustments` credit, and `Received` with its rows negative and `success`-toned — so the total
+  states arithmetic rather than a difference, over a `LedgerTotal` carrying `zeroLabel="Paid in
+  full"`. Every row state is on screen: a `peek` door on the multi-line invoice (its lookup link
+  INSIDE the popover, since a button cannot hold a button), a flat `reference` on the single-line
+  one, `meta` qualifying how money came back. `Received` is DERIVED from the charges that carry a
+  payment method — not a second flag to keep in step — and the refundable deposit stays OUT,
+  because a ledger earns trust by summing exactly what its label claims. The fixture is
+  deliberately uneven (an unpriced charge, one issued invoice, a one-row group) because a tidy
+  one verifies nothing.
   THE ACTION-GATING LAW is still the worked example: a not-ready Issue is DISABLED and the
-  reason is a co-located `Callout` at the gate's SCOPE, once — an invoice's own inconsistency
-  (a charged line with no method) in its drawer, a broken record premise (no customer / invalid
-  tax ID) at the section top; self-evident empties stay silent, and NEVER prose beside a CTA.
-  Issuing gates on record premises only — never silently on stage. Issue sits in the DRAWER's
-  footer, which is the one place a CTA right-aligns (an overlay footer; on the page it would
-  ride the control column). It is also the worked example of **an irreversible action taking an
-  ID, not a captured object** — the confirm re-resolves the invoice from its key, so the quoted
-  total is the one that will be billed even when the press was held for a charge cell's write
-  (data_entry.md § Inline edit).
+  reason is a co-located `Callout` at the gate's SCOPE, once — an invoice's own inconsistency (a
+  charged line with no method) on that line, a broken record premise (no customer / invalid tax
+  ID) at the section top; self-evident empties stay silent, and NEVER prose beside a CTA.
+  Issuing gates on record premises only — never silently on stage. It is also the worked example
+  of **an irreversible action taking an ID, not a captured object** — the confirm re-resolves the
+  invoice from its key, so the quoted total is the one that will be billed even when the press
+  was held for a charge cell's write (data_entry.md § Inline edit).
 - **Document set — the OUTPUT desk, the last WORK section** (the composition rules' output
   law worked on the record surface: the top is intake, the bottom produces on demand).
   Forms group PER PARTY on the `SubsectionStack` beat — each party a `SubsectionHeading` +

package/examples/tpl_item_list.tsx

@@ -159,7 +159,7 @@ const ASSIGNEES = [...new Set(HO_SO.map((r) => r.phuTrach))].map((n) => ({ label
 // Columns defined ONCE — Table renders the header from these and each
 // TableCell takes its width/align by position; the ⋯ is the trailing gutter.
 // `priority` = the MOBILE contract: when the container can't fit every column
-// the highest numbers drop first (Received → Tasks → Status), the identity +
+// the highest numbers drop first (Received → Status), the identity +
 // Customer + Fee survive longest, and at the register floor rows STACK
 // (label-over-value) so nothing is lost — the drawer carries full detail
 // either way.
@@ -715,8 +715,8 @@ function EnterDataDialog({ open, onOpenChange, seedDocs, onCreate, onCreateMany
           <View style={{ paddingHorizontal: 24, paddingBottom: 12, gap: 12 }}>
             <Text size="xs" color="muted">
               {variant === "export"
-                ? "The export case starts in Processing — details, tasks, and payment live on the record itself."
-                : "The import case starts in Processing — details, tasks, and payment live on the record itself."}
+                ? "The export case starts in Processing — details and payment live on the record itself."
+                : "The import case starts in Processing — details and payment live on the record itself."}
             </Text>
             <FormField label="Customer">
               {khach === "" ? (
@@ -779,9 +779,8 @@ export function TplItemList() {
   const [search, setSearch] = useState("");
   const [page, setPage] = useState(0);
   const [openMa, setOpenMa] = useState<string | null>(null);
-  // ONE task state per record — the register column, its peek popover, and the
-  // drawer all read and write the same list. Paid state lifts the same way:
-  // settling the ledger in the drawer flips the row's Unpaid/Print/menu live.
+  // Paid state is LIFTED, not owned by the drawer: settling the ledger inside the
+  // drawer flips the row's Unpaid/Print/menu live, because both read one source.
   const [paidMap, setPaidMap] = useState<Record<string, boolean>>({});
   const daThuOf = (r: HoSo) => paidMap[r.ma] ?? r.daThu;
   // The register rows are state: the create dialog PREPENDS a real row and