Keep a marker outside a table where the selection put it

[kylemcd]

Follow-up to #82, fixing a regression it introduced. 0.1.15 doesn't have this bug, but the next release would.

When one end of a selection is in a table, clampToTableCells trimmed the other end too, and leading whitespace can span lines:

• A selection starting on the blank line above a heading (or at the end of the paragraph above it) wrote <!--c:id-->## Plan.
• A selection ending just after a heading's ## wrote ##<!--/c:id--> Next.
• A selection ending just after a list bullet wrote -<!--/c:id--> item.
• A selection starting past the closing pipe of a table's last row (End, then Shift+Down) wrote <!--c:id-->## Next on the heading below.

Either way the line stopped being a heading or list item. A table that opens directly under that heading stopped rendering too. Repair moved an older anchor's marker onto the heading the same way, then reported "Repaired 1 table comment."

The trim still decides whether an end belongs to a table. Where the markers go now:

• Outside every table: the marker stays where the selection put it, as in 0.1.15.
• End whose whitespace runs onto later lines (a triple-click): the end comes back to its text.
• Start on a table's own line, past its last pipe: the marker goes inside the nearest cell, which adds no table text to the comment. The card then lines up with that row, not with the block below.

Testing

• npm run check passes (295 tests). Eight new tests, all failing on main:

  • a start at the end of the paragraph above a heading;
  • a start on the blank line above a heading;
  • an end after a heading's ## ;
  • an end after a list bullet;
  • Repair of an older anchor that starts above a heading;
  • a start past the last pipe of a body row, of a header-only table, and before a list.

  Every existing table-anchoring test passes unchanged.

• Obsidian, starting from the blank line above ## Plan: the comment kept the heading and all three rows.

• Obsidian, starting past the last row's pipe and ending in a second table under ## Next: both tables rendered with all their rows and the heading stayed a heading.

• Reviews:

  • A fresh-agent regression review of Fix comments on Markdown tables #82's merged code found the original bug.
  • A review of this PR's first commit found the last-pipe case, fixed in the second commit.
  • The first review's fuzz run of Repair over about 14,000 generated notes didn't change note text or lose a marker.
  • A third review fuzzed adding comments and Repair against main and 0.1.15. It found no case where this PR breaks a table, heading, list or fence that 0.1.15 didn't also break, and no crashes or lost text.

• Known, not fixed here: a selection starting at the very end of a closing code fence, --- or === line still writes its marker there and breaks that line. 0.1.15 does the same, and so does every comment on main that doesn't touch a table. Only main's unreleased table code avoided it, by trimming the start forward, which is what broke headings and lists. Fixing it means changing where every comment puts its markers next to such lines, so it's a separate change.