normalizeCellRange now optionally takes TableData and runs the fixed-point
expander before returning. normalizeRange looks the table up from layout
and threads it through, so peer cursor rendering and programmatic ranges
get the expanded rectangle even without a write-time normalization pass.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The drag-selection and Shift+Arrow cross-cell paths now run the cell range
through expandCellRangeForMerges before storing it on the selection. The
highlight is built from this stored value, so users see the exact area
that will be merged before they open the context menu. applyTableCellStyle,
which reads tableCellRange directly without normalization, also gets the
expanded range for free.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Returns 'none' | 'canMerge' | 'canUnmerge' plus the data the menu needs to
act. Pure function over Doc, parent map, cursor, and selection range — no
DOM, no editor reference, fully unit-testable. Range presence wins over
canUnmerge so a user inside an existing merged cell can still grow the
merge by selecting a wider range.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Thin wrapper around computeTableMergeContext that the frontend context menu
calls when it opens, so the merge/unmerge slot can render the right label,
icon, and enabled state without duplicating selection logic.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The auto-expansion path will routinely produce ranges that contain a
pre-existing merged cell, so we lock in the current Doc.mergeCells
behavior: outer top-left absorbs inner span and inner content, every
other cell ends up covered.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The Cell section of the table context menu now exposes one slot whose
label, icon, and enabled state follow editor.getTableMergeContext().
A single non-merged cell shows "Merge cells" disabled (discoverability),
a 2+ cell range shows it enabled, and a merged cell shows "Unmerge cells".
Replaces the previous Split-only entry, which was unreachable for users
who never knew the merge API existed.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Design additions to docs/design/docs/docs-tables.md cover cell range
normalization (fixed-point bounding-rect expansion over merged cells)
and the hybrid Merge/Unmerge context-menu slot. The paired task files
under docs/tasks/active/ document the bite-sized TDD plan used to
implement them and capture lessons about the docs-package dist import
boundary and the cursor-on-covered-cell pitfall.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

buildCellRangeRects was drawing each non-covered cell in the range using
the anchor column's pixel width and the anchor row's height, so a merge
top-left with colSpan/rowSpan > 1 was highlighted only over its original
single-cell footprint. The new Merge UX exposes this constantly because
selections are now auto-expanded to include any merged cell they touch.

Use LayoutTableCell.width (which already sums spanned columns) and sum
rowHeights over the source cell's rowSpan for the height.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

detectTableBorder previously considered every column/row boundary a valid
resize handle regardless of whether a merged cell swallowed that segment
at the cursor's row/column. Hovering the middle of a 1×3 merged cell
showed col-resize, which looked broken.

Locate the hover row/col, walk to each neighboring cell's merge top-left
via findMergeTopLeft, and skip the border when both sides share a merge.
Call sites in text-editor.ts now thread tableData through so the detector
can run the merge check.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Right-clicking near the bottom or right edge of the viewport previously
produced a menu that overflowed and was partially clipped. Measure the
rendered menu in a useLayoutEffect, shift it up/left if it overflows,
and re-run the check when showColors toggles (it grows the menu).

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The container has an animate-in fade-in-0 zoom-in-95 class. useLayoutEffect
fires while the menu is still scaled at 95%, so getBoundingClientRect
reports a height smaller than the final laid-out size. Clamping on that
scaled height leaves the bottom clipped after the animation completes.
offsetWidth/offsetHeight report unscaled layout dimensions and fix it.
Also bump the viewport padding from 4px to 8px for a little breathing room.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

resolveTableCellClick was reading tl.rowYOffsets directly, which are in
the table's own contiguous coordinate system and do not account for the
gap between pages when a table splits across them. Clicking the first
row on page 2 of a 1+2 split 3x3 table produced a localY far larger than
any rowYOffset, so the function fell through to its last-row fallback
and picked the wrong row.

Iterate paginatedLayout.pages[].lines for the table's blockIndex,
reconstruct each row's absolute Y as pageY + pl.y, and pick the row
whose band contains mouseY. The caller now passes canvas-logical mouseX
and mouseY directly and the old localX/localY threading is gone from
both the click and drag-selection call sites.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

buildCellRangeRects previously derived each row's Y from
(tablePageY - rowYOffsets[0]) + rowYOffsets[r], which assumes the table
renders in a single contiguous band. When the table spans pages, rows
after the break live on a new page whose top is not related to the
first row's Y, so the highlight ended up stacked near the top of page 1
instead of on the actual rows.

Build a row → absolute Y map by walking paginatedLayout.pages[].lines
for the table and use that per-row Y in the rect output.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

When a merged cell's rowSpan crosses a page break, both pages re-draw
the full cell content at different virtual origins. The canvas clip
masks whatever does not fit in each page, but lines near the break
land inside both pages' content areas and appear twice.

Fix by assigning each line of a merged cell to a single owner row based
on its center Y in table-logical coordinates, then skipping the line
when the owner row is not inside the current page's physical row
range. renderTableContent now takes a pageStartRow parameter so the
caller can distinguish "swept back for a merged cell" (renderStartRow)
from "first row actually laid out on this page" (pageStartRow). The
same filter gates list markers so they follow their block's first line.
Non-merged cells on swept-back rows are also skipped outright since
their content was already drawn on an earlier page.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The previous pass deduped merged-cell text across a page break, but the
cell outline was still drawn as one full rectangle per page with the
canvas clip trimming either the bottom or the top. That left the page 1
slice with no visible bottom border and the page 2 slice with no visible
top border, so the split looked like one half-open shape on each side.

Recompute the cell's visible row range (Math.max(r, pageStart) to
Math.min(r + rowSpan, rowEnd)) and size the background fill and the
four border lines to that clipped range. Each page now renders the
merged cell slice as a fully closed four-sided cell that matches the
adjacent rows on the same page.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Two follow-ups to the merged-cell page-break rendering:

Cursor placement: resolvePositionPixel anchored the cursor to the cell's
top-left row's PageLine and added the line's y within the cell. For a
merged cell split across pages, lines owned by later rows landed in the
empty space on page 1 instead of following their row to page 2. Find
the line's owner row in table-logical coordinates, look up that row's
PageLine, and derive the cursor Y from it so Arrow Down across a page
break lands on the actual line on the next page.

Border hit-testing: resolveTableFromMouse mapped mouseY through a
single tableOriginY taken from row 0, which made localY meaningless
for pages past the first. Walk each page's line range for the table,
only resolve inside the band the cursor is actually over, and return
pageFirstRow/pageLastRow so detectTableBorder can ignore row borders
belonging to rows on a different page. Hovering empty space below row
0 on page 1 no longer flashes a row-resize cursor.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

renderTableContent now shifts merged-cell text on a continuation page so
the first visible line sits at (visible-row top + padding). The cursor
computation in resolvePositionPixel needed the same adjustment or the
caret would hover above where the text actually draws.

Extract findMergedCellOwnerRow and computeMergedCellLineShift as shared
helpers in table-renderer.ts and use them from peer-cursor.ts. The
cursor now finds ownerRow, looks up the cell's first row on that page,
and adds the same shift the renderer uses so the caret lands on the
rendered text line.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The previous heuristic assigned each line to a row based on where its
center fell in the table-logical Y axis. When row heights were larger
than the line height (e.g. three 20-px lines merged into three 28-px
rows), two lines packed into the same row and the third line overlapped
the row-2 boundary. Splitting at a page break then showed "1, 2, 3" on
page 1 with the tail line straddling the break, instead of "3" moving
cleanly to page 2.

Replace findMergedCellOwnerRow + computeMergedCellLineShift with a
single computeMergedCellLineLayouts helper that walks lines in order
and advances to the next spanned row as soon as one fills up. Each
returned entry is { ownerRow, runLineY } in table-logical coordinates,
so the renderer and resolvePositionPixel can drive their Y from the
same source and stay aligned on continuation pages.

Both call sites now look up lineLayouts[targetIdx] instead of running
separate owner/shift math, and for rowSpan === 1 the result matches the
old "cellY + padding + line.y" formula so non-merged cells render
unchanged.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

buildCellRangeRects drew one rect per selected cell anchored at the
cell's top row with the full row-span height summed from rowHeights.
For a merged cell whose span crosses a page break that rect extended
down past row 0's actual bottom on page 1, painting the highlight into
the empty area below the table on page 1 and leaving no highlight on
page 2's slice.

Walk the cell's spanned rows via the rowYMap, detect a page break when
the next row's absolute Y is not equal to the current segment's
(top + accumulated height), flush the current rect on the break, and
start a new segment anchored at the new row's page position. Non-merged
cells (rowSpan === 1) produce a single segment so the existing output
is unchanged.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The multi-line branch of buildRects advanced midY by the first line's
height to paint "middle" rows, which assumes the cell's text flows on a
single continuous Y axis. Selecting all content in a merged cell that
spans a page break then painted the middle-line strip into the empty
space below row 0 on page 1, because lines 2 and 3 actually live on
page 2 at completely different absolute Y values.

Find the cell's start/end line indices, run the same
computeMergedCellLineLayouts helper the renderer uses, and emit one
rect per line in [startLineIdx, endLineIdx]. Each rect's Y is looked up
from the owner row's PageLine, so the highlight lands on whichever page
actually renders that line. Width is cell-clamped in the middle and
start/end-clamped on the edge lines.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

resolveOffsetInCellAtXY computed a single cellPageY from the cell's
top-left row's PageLine, then matched the click against cell.lines[li].y
on a continuous Y axis. For a merged cell split across pages, line 1 and
line 2 live on a later page at different absolute Y values, so a click
next to "2" on page 2 fell through the loop and returned the last line's
offset ("3" in the 1\n2\n3 example).

Replace the single-origin math with computeMergedCellLineLayouts: build
each line's absolute rendered Y by looking up its owner row's PageLine
and adding the row-local delta, then pick the first line whose
(lineAbsY + line.height) passes the click. A row → PageLine cache keeps
the per-click cost bounded.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

renderTableContent set ctx.fillStyle / strokeStyle with
\`style.color ?? Theme.defaultColor\`. The ?? operator only treats null
and undefined as missing, so an inline whose \`color\` is an empty string
left the canvas state unchanged — setting fillStyle to '' silently
keeps whatever was there before, which happened to be the blue local-
selection rect color on any page that drew a selection highlight. Table
text on page 2 (selected merged cell) then rendered in the selection
color instead of the theme's text color while page 1 stayed white
because nothing had set fillStyle to a selection color yet.

Switch to \`style.color || Theme.defaultColor\` to match the non-table
renderRun path (doc-canvas.ts:673). Empty strings now correctly fall
through to the theme default, and fillText/strokeText always produce
the intended color regardless of the stale canvas state left by an
earlier drawing pass.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Captures the patterns and pitfalls discovered after the initial plan:
the shared line-layout helper, per-page row filter, ?? vs || for
inline colors, center-of-line ownership failure mode, cell-internal
multi-line rect path, and per-page resolveTableFromMouse.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

findPageForPosition walks top-level document blocks, so a cursor whose
blockId belongs to a table cell resolved to undefined and the ruler
fell back to page 0. Clicking a cell on page 2 then kept the ruler
indicator on page 1.

Use the already-computed cursorPixel.y instead: walk paginatedLayout
pages and pick the one whose Y range contains the cursor. That handles
table cells, merged-cell continuations, header/footer contexts, and
non-table blocks with the same code path. Also resolve the cursor's
block style through the parent-map when the cursor is inside a cell so
the ruler's indent markers reflect the table block's own style.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>