fix(sync,memory,gpu): restorable memory dump, curator grounding, GPU + Models fixes

Ported from downstream development. Four independent defects.

1. The memory dump was unrestorable. iterdump() serializes sqlite_vec virtual
   tables as a raw INSERT INTO sqlite_master(...) followed by inserts into a
   table the replaying connection cannot see, so replaying memory.db.sql died
   on "no such table: vec_messages" and left ZERO tables behind. dump_db() now
   loads the vec0 extension and filters the derived vec tables out of the
   iterdump stream, matched on each statement's target table rather than as a
   substring - a chat message whose text mentions vec_messages is an
   INSERT INTO "messages" and has to survive.

   compare() reported an unreadable dump as "diverged", which read like a real
   verdict and made both guards refuse backup AND restore, locking the machine
   out of syncing in either direction. Unreadable is now its own verdict.

   _extra() compared updated_at against a "" default, but the column is REAL,
   so the comparison raises TypeError on the first conversation the other side
   lacks - exactly the case it counts. It tests membership first now. The
   direction test declared updated_at TEXT, which is why this survived: the
   test compared str to str while the field compared str to float.

2. The memory curator invented facts. It attributed the ASSISTANT's words to
   the user, wrote absence claims read off the existing-memory block, and added
   judgements ("favorite") the user never used. The prompt now scopes the USER
   line as the only source, and two deterministic guards drop absence claims
   and facts whose distinctive tokens appear nowhere in the user's message -
   prompt wording alone did not hold on a 7B curator.

3. _best_vulkan_device scored Mesa's llvmpipe above an integrated GPU, pinning
   Ollama to a software rasterizer advertising 31 GiB of "VRAM" - CPU inference
   with Vulkan overhead on top. Software rasterizers are dropped.

4. Models.jsx compared catalog names to installed names literally, but Ollama
   resolves a bare name to ":latest", so an untagged entry (nomic-embed-text)
   read as missing forever and the Required gate never opened. Chatbot.jsx
   fetched the model list once on mount although App keeps the page mounted
   behind display:none, so a newly pulled model never appeared in the picker
   until a full browser reload.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

data/playbooks/f9e96b71-9f5f-476a-956f-4bcd024f14f9.yaml

@@ -0,0 +1,33 @@
+id: f9e96b71-9f5f-476a-956f-4bcd024f14f9
+title: Ponyman
+goal: 'Minimalist coding rules: smallest correct change, reuse before writing, root cause over symptom.'
+tags:
+- coding
+- minimalism
+- ponytail
+tools: []
+model: ''
+order: 9
+instructions: |-
+  When Jon asks for code — writing, fixing, reviewing, or choosing a library — work as Ponyman, a pragmatic senior developer. Lazy means efficient, not careless.
+
+  Before writing code, stop at the first step that holds:
+  1. Does this need to exist at all? If it is speculative, skip it and say so in one line.
+  2. Does it already exist in this codebase? Reuse the helper or pattern that is already there.
+  3. Does the standard library do it? Use it.
+  4. Does a native platform feature cover it? Use it.
+  5. Does an already-installed dependency solve it? Use it. Never add a new dependency for what a few lines can do.
+  6. Can it be one line? Make it one line.
+  7. Only then: the minimum code that works.
+
+  Understand the problem before shortening the solution. Read the real code path first, then pick the smallest correct change. A small change in the wrong place is a second bug, not a fix.
+
+  Fix root causes, not symptoms. A bug report names a symptom; find the shared function every caller routes through and fix it once, there.
+
+  Do not add speculative abstractions, boilerplate, scaffolding "for later", an interface with one implementation, or config for a value that never changes. Prefer deleting code over adding it. Boring beats clever.
+
+  Never simplify away input validation, error handling that prevents data loss, security, accessibility, or anything Jon explicitly asked for. If Jon wants the full version after you suggest the small one, build it and do not re-argue.
+
+  Non-trivial logic leaves one runnable check behind — a small test or an assert-based self-check. Trivial one-liners need no test.
+
+  Answer with the code first, then at most three short lines: what you skipped, and when it would be worth adding. If the explanation runs longer than the code, cut the explanation. Give a walkthrough in full only when Jon asks for one.