android: the editor draws the checklist instead of the markup for one

2992. A checklist item is a real Checkbox with its text beside it, so a box can be
ticked while looking at the note — which is what M304 left undone. It changed where
a checklist is STORED and never changed what the editor draws.

The body is split into blocks and joined back on every edit, so the note underneath
is the same markdown string it was this morning. Nothing below the editor can tell
this exists: no migration, no protocol change, no new shape on the wire.

A run of prose lines is ONE block, not one per line. Typing a paragraph has to feel
like typing a paragraph, and a separate field under every sentence would break the
caret mid-sentence. Only a checklist item earns a block, because only a checklist
item needs a widget.

Two things that look like detail and are not:

  * A block carries its own TextFieldValue, and an ID that survives insertion.
    Compose keys fields by position unless told otherwise, so adding an item would
    otherwise move every caret below it up a row. Content cannot be that key —
    two empty items are identical and neither is the other.
  * Focus is hoisted to the screen rather than kept inside BlockBody, because the
    toolbar's checklist button also asks for one. Two owners of one cursor is one
    too many.

Return on an item makes the next item and puts the caret in it; on an EMPTY item
the block becomes prose, which is how a list ends and how you get a paragraph after
one — the same rule the plain text field used, now with somewhere to land. It
appends rather than splitting at the caret: splitting an item in two is a rarity,
and the caret is at the end for every ordinary use of that key.

The core gains `render_item` and `DerivedItem.line`; `item_lines` and
`checklist_lines` are gone, subsumed. Every renderer that walks a body line by line
needs the text, the state and the position TOGETHER — asking for them separately is
how two calls come to disagree about a body that changed between them. The card now
reads its items from the body for the same reason, instead of from note.items,
which is the same list by a longer route and one save behind.

WANTS A DEVICE PASS, and the focus behaviours are what to look at: return making a
row and landing in it, return twice at the end of a list getting you a paragraph,
and rotation restoring the right field. CI can only prove this compiles.

android/ffi/src/models.rs

@@ -49,6 +49,33 @@ pub struct Note {
     pub updated_at: Option<String>,
 }
 
+/// A checklist item as it sits in a note's body.
+///
+/// Mirrors `derive::DerivedItem`. Carries the LINE because every renderer that walks
+/// a body line by line needs the text, the state and the position together — the card
+/// to draw a box in the right place, the block editor to know where one block ends.
+#[derive(Debug, Clone, uniffi::Record)]
+pub struct BodyItem {
+    pub line: u32,
+    pub text: String,
+    pub checked: bool,
+}
+
+impl From<thoughtsync_core::local::derive::DerivedItem> for BodyItem {
+    fn from(i: thoughtsync_core::local::derive::DerivedItem) -> Self {
+        let thoughtsync_core::local::derive::DerivedItem {
+            text,
+            checked,
+            line,
+        } = i;
+        BodyItem {
+            line,
+            text,
+            checked,
+        }
+    }
+}
+
 /// An Android build the linked server is offering, already judged to be newer.
 ///
 /// A mirror rather than a re-export of `client::ClientRelease`, for the same