feat: read WorkTable's DSL and draw the store schema

[pathscale]

Reads every worktable! in apps/gui/src/db/schema and draws it: a Schema tab
beside Analytics, with the tables laid out by reference depth so the two that
reference nothing sit in the first column and the fifteen that carry a
project_id fan out to the right.

The reader

crates/wt-schema parses the DSL into data: columns with types, primary key,
generators, optional and using <backend>, plus indexes, the
update/delete/in_place queries, persist, version, partition_by and
page_size. That is WorkTable's whole grammar, not the subset this app happens
to use, so the reader also works on a schema file it has never seen.

The grammar is mirrored rather than borrowed: WorkTable's parser lives in its
proc-macro crate and returns generated code, not a description of what it read,
and syn stops at the token stream inside the parentheses. Unknown sections are
an error, because a reader that shrugs at what it does not understand describes
a schema that is quietly missing something.

Column comments come back too. They are //, not ///, so the lexer drops them
before any parser sees them; they are recovered by line number. In this codebase
that prose is most of what a diagram has worth showing.

Where the edges come from

The DSL declares no foreign keys. project_id is a String like every other
column, so the edges are proposed from naming and corrected by hand in
schema.overlay.json, and the two are drawn differently: solid for inferred,
dashed for declared, faded for a reference the source documents as often empty.
Rendering them identically would claim a certainty nobody has.

Anything the convention cannot resolve is reported with suggestions rather than
dropped. The overlay currently closes all nine of those, and two of them are why
the mechanism exists at all: item_completion.id and usage_session.id are
primary keys that are themselves references, which no naming rule can see.

Read-only, deliberately

WorkTable persists rows with rkyv, positionally, and nothing on disk records
which columns produced them, so a table whose columns change reads every
existing row through the new layout with no error anywhere. A designer that
writes a worktable! has to drive SCHEMA_FINGERPRINT and the migration in the
same breath, or it is a data-loss tool with a nice diagram. This parses and
describes; it never writes Rust.

Verification

The parser is checked against db/fingerprint.rs, which states every table's
column list in order and is maintained by hand rather than generated from these
files. Reconstructing it from the parse is therefore a real independent check: a
missed column, a reordered one or a skipped file each break it by name, and it
will also fail the day someone adds a column and forgets the fingerprint bump.

Green: 8 Rust tests, 6 layout tests, tsc --noEmit, biome, and the i18n audit.

Not verified: how it looks. No frontend node_modules exists in any checkout
on this machine, so I borrowed one rather than installing anything. With it the
fixture app crashes at boot with REACTIVITY_HALTED ... reading 'models' before
any of this code runs. I reproduced the identical crash on master, so it is not
this change, but I cannot tell whether it is a real master bug or an artifact of
the borrowed dependency set. The diagram wants a look, and ps-qa outcomes, before
anyone calls it finished.

Note

The diagram reads a committed JSON file rather than a Tauri command, so it
renders in the browser fixture with no build and no instance, and a schema change
reaches review as a diff of the drawing's input. scripts/generate-schema.sh
rebuilds it. Biome is told to leave that file alone: its formatter is
serde_json's, so formatting it here would make every regeneration produce a
whitespace diff that the next --write undoes.