web: the editor draws the checklist too

2992's other half. The browser was the last surface still showing `- [ ] ` as
markup: cards rendered and ticked checkboxes, the editor did not.

Same shape as Android, deliberately. notes/blocks.ts mirrors EditorBlock.kt —
splitBlocks, joinBlocks, afterEnter, withoutIndex, plusTask — because the two
editors should behave alike and the cheapest way to keep them that way is for the
code to read alike. `body` becomes a computed over the blocks, so every save,
baseline check and draft still reads the one markdown string they always did.

markdown.ts now exports parseTaskLine and renderTaskLine, and parseMarkdown uses
the former. The read view and the editor's block split had been matching the same
grammar through two separate copies of one regex; now they agree by construction.

Two places the web can do better than Compose, and does:

  * Backspace at the start of an empty item removes it. A browser sends a real
    keydown for Backspace; an Android soft keyboard sends an IME delete that never
    surfaces as one, which is why that surface only has Enter-on-empty.
  * Prose fields size to their text — rows="1" plus a scrollHeight fit, which beats
    guessing a row count that is wrong the moment a line wraps.

KNOWN, and the same on both surfaces: typing `- [ ] ` by hand into a prose block
leaves it prose until the note is reopened. Blocks are split when the editor loads,
not re-derived per keystroke — re-splitting mid-type would move the caret. The
toolbar button is the intended path. Converting on blur would fix it and is worth
doing to BOTH editors at once rather than letting them drift.

frontend/src/notes/markdown.ts

@@ -66,6 +66,27 @@ export function parseInline(text: string): InlineToken[] {
 // which is at least consistent.
 const TASK_RE = /^\s*[-*] +\[([ xX])\](?: +(.*))?$/;
 
+export interface TaskLine {
+  checked: boolean;
+  text: string;
+}
+
+/** One task line's parts, or null when the line is prose.
+ *
+ *  Exported so the EDITOR's block split (notes/blocks.ts) and this read-view parser
+ *  agree by construction rather than by comment. One grammar, one matcher. */
+export function parseTaskLine(line: string): TaskLine | null {
+  const m = TASK_RE.exec(line);
+  return m ? { checked: m[1] !== " ", text: m[2] ?? "" } : null;
+}
+
+/** One item as the body line that stores it, in canonical form — `- [x] `, lowercase,
+ *  and no trailing space when the item is empty so a round trip does not grow it. */
+export function renderTaskLine(text: string, checked: boolean): string {
+  const mark = checked ? "x" : " ";
+  return text ? `- [${mark}] ${text}` : `- [${mark}]`;
+}
+
 export function parseMarkdown(text: string): Block[] {
   const lines = (text ?? "").split("\n");
   const blocks: Block[] = [];
@@ -124,15 +145,15 @@ export function parseMarkdown(text: string): Block[] {
     // Task list, BEFORE the plain bullet below — which would otherwise swallow
     // `- [ ] x` as an ordinary list item and leave the brackets showing. Same
     // ordering reason as `code` being matched before emphasis in INLINE_RE.
-    if (TASK_RE.test(line)) {
+    if (parseTaskLine(line)) {
       flushPara();
       const items: InlineToken[][] = [];
       const tasks: TaskMeta[] = [];
       while (i < lines.length) {
-        const m = TASK_RE.exec(lines[i]);
-        if (!m) break;
-        items.push(parseInline(m[2] ?? ""));
-        tasks.push({ index: taskIndex, checked: m[1] !== " " });
+        const task = parseTaskLine(lines[i]);
+        if (!task) break;
+        items.push(parseInline(task.text));
+        tasks.push({ index: taskIndex, checked: task.checked });
         taskIndex++;
         i++;
       }