fix(tasks): a task's kind is correctable — the Kind select stops lying (#3129)

`kind` was accepted at CREATE on both doors and dropped at UPDATE on both:
update_task had no such parameter, and the REST PATCH allow-list never read
the field. So a task filed under the wrong kind could never be corrected.

The frontend made it worse by looking like it worked. TaskEditorView binds a
Kind select, marks the form dirty, and HAS ALWAYS SENT `kind` in the update
payload — the store even types it. The route ignored it, returned 200, the
view optimistically updated, the toast said "Task saved", and the old value
came back on reload. Silent success, same class as #2709.

Found by trying to re-file #3126 as a spike after deploying 0091. It could
not be done; the task had to be recreated as #3128 and the original
cancelled.

One seam, not two doors. `minted_kind()` lives in services/notes.py because
the REST route cannot import an MCP tool module and a second spelling of the
list is how the doors would come to disagree. Both create and update route
through it, so a bogus kind is now a readable error rather than a
CheckViolationError surfacing as a 500.

TaskKind joins TaskStatus and TaskPriority as a real enum, and update_note
validates task_kind exactly as it already validated those two — the field
had been reaching setattr through the hasattr guard with no validation at
all, unnoticed only because no door ever offered it.

The `-> plan` question #3129 raised is answered in code rather than left
implicit: MINTABLE_KINDS is work/issue/spike, deliberately NARROWER than the
column's CHECK. `plan` stays a valid stored value because historical
plan-tasks carry it and must stay writable; it is simply not a value any
door hands out, and the refusal names start_planning because a caller
reaching for it wants a plan. The whitelist and the policy answer different
questions and are not the same list.

Every new test reads the value BACK. One that only asserted the call
succeeded would have passed against the broken code — the route returned 200
while dropping the field, which is how this survived long enough to be found
by hand.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/scribe/services/notes.py

@@ -5,7 +5,7 @@ from datetime import date, datetime, timezone
 from sqlalchemy import func, or_, select, text
 
 from scribe.models import async_session
-from scribe.models.note import Note, TaskPriority, TaskStatus
+from scribe.models.note import Note, TaskKind, TaskPriority, TaskStatus
 
 logger = logging.getLogger(__name__)
 
@@ -366,6 +366,37 @@ async def get_or_create_note_by_title(user_id: int, title: str) -> Note:
     return await create_note(user_id, title=title)
 
 
+# Kinds a caller may MINT. Narrower than what the COLUMN holds: `plan` is a
+# valid stored value — historical plan-tasks carry it and must stay writable —
+# but plans became milestones in 0066, so no door hands out a new one. The
+# CHECK whitelist and this policy answer different questions, which is why
+# they are deliberately not the same list.
+MINTABLE_KINDS = ("work", "issue", "spike")
+
+
+def minted_kind(kind: str) -> str:
+    """Validate a kind a caller is asking to WRITE, or raise saying why.
+
+    Lives here rather than in either door so both share one copy: the REST
+    route cannot import an MCP tool module, and a second spelling of this
+    list is how the two doors would come to disagree.
+
+    Raises rather than falling back to 'work'. A silently-corrected kind is
+    the defect this exists to end (#3129: the editor's Kind select reported
+    success and changed nothing), and a caller naming a kind we do not know
+    has a wrong idea that an error corrects and a default hides.
+    """
+    if kind in MINTABLE_KINDS:
+        return kind
+    if kind == "plan":
+        raise ValueError(
+            "kind='plan' is retired — plans are milestones. Call "
+            "start_planning(project_id, title) to begin one. Existing "
+            "plan-tasks keep the value and stay editable."
+        )
+    raise ValueError(f"kind must be one of {MINTABLE_KINDS}, got {kind!r}")
+
+
 async def update_note(user_id: int, note_id: int, **fields: object) -> Note | None:
     async with async_session() as session:
         result = await session.execute(
@@ -391,6 +422,20 @@ async def update_note(user_id: int, note_id: int, **fields: object) -> Note | No
                     value = TaskPriority(value).value
                 except ValueError:
                     raise ValueError(f"Invalid priority: {value!r}. Must be one of: {[p.value for p in TaskPriority]}")
+            elif key == "task_kind" and isinstance(value, str):
+                # Same shape as status/priority above, and for the same
+                # reason: a kind the column will refuse should fail here with
+                # a readable message, not as a CheckViolationError from the
+                # database. Before this, `task_kind` reached setattr through
+                # the hasattr guard with no validation at all — but no door
+                # ever offered it, so a task's kind was write-once (#3129).
+                try:
+                    value = TaskKind(value).value
+                except ValueError:
+                    raise ValueError(
+                        f"Invalid kind: {value!r}. Must be one of: "
+                        f"{[k.value for k in TaskKind]}"
+                    )
             elif key == "tags" and isinstance(value, list):
                 value = _normalize_tags(value)
             setattr(note, key, value)