core: the body is the checklist, and checklist_items is gone

M304 steps 2 and the client half of 4, together — they cannot be separated. A
commit where the store writes items into the body while push.rs still reads them
from a table is one that silently pushes the wrong list, and dev publishes to the
dev channel on every green build.

Store:
  * load_items becomes items_of(body) — a parse, not a query. An item's id is its
    ORDINAL, which is all it ever amounted to: push.rs sent text and checked and
    never an id, and both sides replaced the whole list on every sync.
  * add_item / update_item / delete_item route through update_note, so they get
    revision snapshotting, #tag re-derivation and the dirty/updated_at bookkeeping
    without any of it being written a second time.
  * create_note folds its items: input into the body, and syncs tags from the
    FOLDED body — an item can carry a #tag too.
  * display_title no longer takes items, because items ARE body lines now. It
    strips the task marker instead: a list-only note is still named by its first
    item, and calling that note "- [ ] milk" would show someone the storage.

Wire: items leave it. A second copy of data already in the body field of the same
message is how the two come to disagree. CLIENT_PROTOCOL_VERSION and
MIN_SERVER_PROTOCOL_VERSION go to 3, which is what makes this safe to land before
the server: a v3 client refuses a v2 server outright rather than pushing a body
whose list the old _apply_note_items would then delete.

Schema v8 folds every existing row into its note's body before dropping the
table. Written in Rust, not SQL: the fold has to produce exactly what
derive::append_item produces, and group_concat only gained a guaranteed ORDER BY
in SQLite 3.44 — a checklist that quietly reordered itself during a migration
would be a poor way to learn that. updated_at and dirty are deliberately left
alone, because the server's migration folds the same rows the same way and both
sides land on identical bodies; marking every note dirty would push a body the
server already has, from every device at once.

NOT deployable yet. The server still speaks v2 and still has note_items, so a
client built from this will refuse to sync until the server half lands.

core/src/local/derive.rs

@@ -155,6 +155,17 @@ fn render_task_line(indent: &str, bullet: char, checked: bool, text: &str) -> St
     }
 }
 
+/// The text of a line with its task marker removed, or the line as it was.
+///
+/// For naming a note: a list-only note is named by its first item, and calling one
+/// "- [ ] milk" would be showing someone the storage instead of the note.
+pub fn strip_marker(line: &str) -> &str {
+    match parse_task_line(line) {
+        Some(t) => t.text,
+        None => line,
+    }
+}
+
 /// Every checklist item in `body`, in the order they appear.
 pub fn extract_items(body: &str) -> Vec<DerivedItem> {
     let mut out = Vec::new();
@@ -237,8 +248,12 @@ pub fn remove_item(body: &str, index: usize) -> String {
 /// cosmetic: the server migration folds existing rows into bodies using the same
 /// layout, so an export taken before the migration and one taken after have to
 /// agree byte for byte.
-pub fn append_item(body: &str, text: &str) -> String {
-    let line = render_task_line("", '-', false, text.trim());
+///
+/// `checked` is a parameter rather than always false because the two migrations that
+/// fold existing rows into bodies have to carry the state those rows were in. A new
+/// item from the UI passes false.
+pub fn append_item(body: &str, text: &str, checked: bool) -> String {
+    let line = render_task_line("", '-', checked, text.trim());
     let trimmed = body.trim_end_matches('\n');
     if trimmed.trim().is_empty() {
         return line;
@@ -378,13 +393,21 @@ mod tests {
         // Prose then a blank line then the list — byte-for-byte what
         // import_export.py:_note_markdown writes, which is what the server
         // migration will fold existing rows into.
-        assert_eq!(append_item("a note", "milk"), "a note\n\n- [ ] milk");
+        assert_eq!(append_item("a note", "milk", false), "a note\n\n- [ ] milk");
         // Nothing between consecutive items.
         let one = "a note\n\n- [ ] milk";
-        assert_eq!(append_item(one, "eggs"), format!("{one}\n- [ ] eggs"));
+        assert_eq!(append_item(one, "eggs", false), format!("{one}\n- [ ] eggs"));
         // A list-only note starts at the first line.
-        assert_eq!(append_item("", "milk"), "- [ ] milk");
-        assert_eq!(append_item("\n\n", "milk"), "- [ ] milk");
+        assert_eq!(append_item("", "milk", false), "- [ ] milk");
+        assert_eq!(append_item("\n\n", "milk", false), "- [ ] milk");
+        // Carries state, which is what the two migrations need of it.
+        assert_eq!(append_item("", "done", true), "- [x] done");
+    }
+
+    #[test]
+    fn strip_marker_names_a_list_only_note() {
+        assert_eq!(strip_marker("- [x] milk"), "milk");
+        assert_eq!(strip_marker("just prose"), "just prose");
     }
 
     #[test]