A checklist is something a note has, not something a note is

`kind` was never a type. A plain TEXT column with no enum and no CHECK behind
it, compared against a hardcoded ("text", "list") tuple in six places;
`note_items` was always an ordinary child table keyed by note_id; serialization
already emitted `items` whatever the kind; and the Android editor already
toggled between the two losslessly, saying so in a comment. The storage has
modelled "a body plus optional checkable items" the whole time. This deletes the
gates that forbade it.

Every surface: the create/PATCH gates, the ?kind= filter and its saved-filter
facet, the three import/export branches, the column (alembic 0025); the core's
`kind` field, its SQLite column (user_version 6), the sync wire, push and pull;
the FFI records and `NoteEdit::Kind`; and on Android `NoteKind.kt`, `DraftKind`,
the compose sheet's Note/List switch, and the branches in the card, the editor
and the chrome.

The editor's note⇄list toggle becomes "Add a checklist" — on both the web and
Android. It is not a conversion any more: nothing moves, nothing is swapped, the
body stays exactly where it is and the note gains somewhere to put items. The
card renders both, in order.

Two things that fell out of the merge rather than being aimed at:

- The Keep importer was DISCARDING `textContent` whenever a note also had
  `listContent`, because the target could only hold one. Both survive now, and
  the test says so.
- Markdown export wrote the body OR the checklist. It writes both.

Protocol goes to v2, floor included: dropping a field a v1 client sends and
expects back is breaking. `title` leaves in step 3 and lands in the same
generation, so it needs no further bump. This is the change that will make the
0.1.227 build on the operator's phone refuse to sync — the in-app updater is
independent of the handshake and remains the recovery path.

The V1 SQLite schema deliberately KEEPS the kind column. V1 is the historical
schema and every later block alters it, so removing it there would make a fresh
database run V1 without the column and then v6's DROP COLUMN against a column
that never existed — "no such column: kind" on every new install.

tests/test_notes.py

@@ -317,9 +317,13 @@ def test_usec_to_dt():
     assert _usec_to_dt(None) is None
 
 
-def test_keep_spec_list_note():
+def test_keep_spec_list_note_keeps_its_text_too():
+    # Keep's own notes carry one or the other, but its textContent used to be
+    # DISCARDED whenever a note also had listContent, because a note could only be
+    # one kind. A note holds both now, so nothing is dropped on the way in.
     kn = {
         "title": "Groceries",
+        "textContent": "for the weekend",
         "listContent": [{"text": "Milk", "isChecked": False}, {"text": "Eggs", "isChecked": True}],
         "labels": [{"name": "shopping"}],
         "color": "TEAL",
@@ -330,7 +334,7 @@ def test_keep_spec_list_note():
         "userEditedTimestampUsec": 1600000100000000,
     }
     spec = _keep_spec(kn, "Takeout/Keep")
-    assert spec["kind"] == "list"
+    assert spec["body"] == "for the weekend"
     assert spec["color"] == "teal"
     assert spec["pinned"] is True
     assert spec["archived"] is False
@@ -348,7 +352,6 @@ def test_keep_spec_text_note_folds_annotation_urls_and_maps_color():
         "attachments": [{"filePath": "img.jpg", "mimetype": "image/jpeg"}],
     }
     spec = _keep_spec(kn, "Takeout/Keep")
-    assert spec["kind"] == "text"
     assert "https://example.com" in spec["body"]
     assert spec["color"] == "orange"
     # attachment path is resolved relative to the note JSON's folder
@@ -360,7 +363,6 @@ def test_native_spec_roundtrip_fields():
         "title": "T",
         "body": "b",
         "color": "blue",
-        "kind": "text",
         "pinned": True,
         "archived": False,
         "created_at": "2026-07-19T00:00:00+00:00",