feat(types)!: drop the blob column type (ADR-0005 Amendment 2)

blob was a dead-end: declarable but never fillable (no literal in either
mode, seed-unsupported), so a blob column could only ever hold NULL. Remove
Type::Blob + Value/CellValue::Blob + the base64 CSV path + the grammar slot
+ completion/render/type-change/seed handling + the binder refusal (whose
message also carried a user-facing "DSL" copy-rule bug). The vocabulary is
now nine types; base64 stays (clipboard OSC-52).

Backward compat is the ADR-0015 migration framework's first real use: a
v1->v2 format bump (CURRENT_SCHEMA_VERSION across serializer/parser/skeleton)
with a migrator that rewrites `type: blob` -> `type: text`, and a forced .db
rebuild from the migrated text when a blob column was actually converted
(the stale .db keeps a STRICT BLOB engine column). Conversion to text is
non-destructive and CSV-free. Covered by a full-stack integration test and a
Tier-4 PTY test that opens a real legacy v1-blob project.

Also sweeps the nine-type vocabulary through CLAUDE.md, requirements.md, the
website (type reference, seed doc, highlight grammar), and the ADR-0030/0033/
0035 cross-references; CHANGELOG Removed entry; handoff-79.

BREAKING CHANGE: the `blob` column type is removed. Existing projects that
declared a blob column are migrated on first open (the column becomes text;
the original project.yaml is kept as a .v1.bak).

website/src/content/docs/reference/generating-sample-data.mdx

@@ -306,9 +306,6 @@ automatically — no override needed.
   (a guard against a typo like `seed members 1000000`). Seed in smaller
   batches if you genuinely need more.
 - `seed members 0` does nothing.
-- A `not null` column seed cannot produce a value for — the only real case is
-  a `not null blob` — makes seed refuse the whole command and name the column,
-  rather than fail partway through.
 
 A whole `seed` is a **single step** in the history: one [`undo`](/using-the-playground/undo-and-history/)
 removes every row it added, not one row at a time.

website/src/content/docs/reference/types.md

@@ -1,14 +1,14 @@
 ---
 title: Types
-description: The ten column types, what they store, and the auto-generating serial and shortid types.
+description: The nine column types, what they store, and the auto-generating serial and shortid types.
 sidebar:
   order: 1
 ---
 
-Every column has a type. The playground offers ten, chosen to cover what a
+Every column has a type. The playground offers nine, chosen to cover what a
 learner needs without the sprawl of a production database.
 
-## The ten types
+## The nine types
 
 | Type | Stores |
 |---|---|
@@ -19,7 +19,6 @@ learner needs without the sprawl of a production database.
 | `bool` | A truth value, shown as `true` / `false`. |
 | `date` | A calendar date, `YYYY-MM-DD`. |
 | `datetime` | A date and time, `YYYY-MM-DDTHH:MM:SS`. |
-| `blob` | Arbitrary binary data. |
 | `serial` | An auto-incrementing whole number — see below. |
 | `shortid` | A short random identifier — see below. |
 
@@ -68,5 +67,5 @@ In advanced mode you may also use familiar standard-SQL spellings, which map
 onto the types above — for example `integer`, `bigint`, and `smallint` are
 all `int`; `varchar` and `char` are `text`; `boolean` is `bool`; `timestamp`
 is `datetime`; `numeric` is `decimal`; `float` and `double precision` are
-`real`. Simple mode uses only the ten names in the table, so it teaches one
+`real`. Simple mode uses only the nine names in the table, so it teaches one
 clear vocabulary.

website/src/grammars/rdbms.mjs

@@ -48,7 +48,7 @@ const repository = {
 		name: 'constant.language.rdbms',
 	},
 	type: {
-		match: '(?i)\\b(text|int|real|decimal|bool|date|datetime|blob|serial|shortid)\\b',
+		match: '(?i)\\b(text|int|real|decimal|bool|date|datetime|serial|shortid)\\b',
 		name: 'support.type.rdbms',
 	},
 	keyword: {