fix(vector): one vector table per notebook with its own embedding width

[mrsibe]

What does this PR do?

Moves vectors from one global vec_embeddings table (fixed FLOAT[1024]) to one
vec0 table per notebook (vec_<notebookId>), with each notebook's embedding
width recorded in vec_metadata. The width now comes from the embedding model
instead of being assumed to be 1024.

Why?

A vec0 table's FLOAT[...] width is fixed at creation. KnowNote asked for
dimensions: 1024 on every embedBatch() call and created vec_embeddings as
FLOAT[1024], so any embedding model that does not return 1024 dimensions fails
at insert time - after the embedding call has already been paid for. #33 reports
exactly this: every embedding model except a 1024-dimensional one cannot index.
VectorStoreManager also carried a mutable defaultDimensions, so whichever
notebook was indexed last decided the width for the next one.

Related issue

Related to #33 (fixes the dimension half of the report; the "only the first of
several selected PDFs indexes" half is untouched).
Design follows #21 by @jimmyken - see the note at the bottom.

What changed?

• src/main/db/index.ts: vec_metadata (notebook_id → table_name, dimensions),
  plus getNotebookVectorTable / createNotebookVectorTable /
  rebuildNotebookVectorTable / dropNotebookVectorTable. Creating a table whose
  stored width differs from the requested one throws - it never drops rows.
  initVectorStore() creates vec_metadata and migrates the old global
  vec_embeddings (vec0 → vec0 INSERT..SELECT, per notebook, then DROP),
  skipping orphan vectors whose notebook no longer exists.
• src/main/vectorstore/SQLiteVectorStore.ts: each store resolves its own table.
  No width → read it from vec_metadata; no table yet → query/count answer
  empty instead of creating a table from a guess. upsert throws on a width
  mismatch instead of letting sqlite-vec fail cryptically.
• src/main/vectorstore/VectorStoreManager.ts: defaultDimensions and
  setDefaultDimensions are gone; the store, not the manager, knows the width.
• src/main/services/KnowledgeService.ts: embeddings are requested with the
  model's native width; the measured width is fed back via
  reconcileVectorDimensions(), which rebuilds the table and marks the
  notebook's documents pending only when the width actually changed.
• src/main/db/queries.ts: deleteNotebook() drops the notebook's vector table;
  cascade deletes do not reach vec0 shadow tables. Also tightens
  createMessage(metadata) from Record<string, any> to
  Record<string, unknown>, matching the column's own $type<...>().
• src/main/vectorstore/vectorTableSql.ts (new): every statement that must
  interpolate a table name - a SQL identifier cannot be a bind parameter - behind
  a single safeIdentifier() allowlist.
• src/main/smokeTest.ts: seeds a legacy vec_embeddings, asserts it migrates
  and stays searchable, and asserts the data-loss case directly (mismatch is
  refused, existing vectors survive, only an explicit rebuild replaces a table).

How was this tested?

• npm run typecheck
• npm test - 20 passing, including the new test/vectorTableSql.test.ts
  (identifier allowlist, per-table statements, placeholder counts)
• npx eslint / npx prettier --check on the touched files (one pre-existing
  no-explicit-any warning at queries.ts:200, unchanged)
• npm run build:unpack && npm run smoke:packaged - PASS, 13 checks, on
  Linux x64. The output shows the legacy table being migrated, the 768- and
  1536-dimensional rebuilds, and the table being dropped with its notebook.

Not tested: a real end-to-end index against a non-1024 provider (OpenAI
text-embedding-3-small at 1536, Ollama nomic-embed-text at 768). The smoke
test covers the storage layer against real sqlite-vec, not a live API call -
worth doing before release.

Screenshots / recordings

Not applicable.

Checklist

• I have reviewed my own changes.
• npm run typecheck passes.
• npm run build passes.
• I have tested the affected user workflow.
• I have not included unrelated changes.
  The Record<string, any> → unknown line is the one exception (it sits in
  a file this PR already touches for deleteNotebook).
• I have updated documentation when necessary.

Desktop / build changes

• Not applicable
• npm run build:unpack passes.
• npm run smoke:packaged passes.

Note on #21

#21 (@jimmyken, d37edfa) is where this design comes from: one vector table per
notebook, a vec_metadata table, widths detected from the model. It could not be
merged as-is - it dropped and recreated a notebook's table whenever a caller
asked for a different width, and the search/reindex call sites had no width to
give, so one wrong default silently destroyed that notebook's vectors; the
vec_embeddings migration was also missing (flagged in review on #21). This PR
keeps the design and changes the rule to "the stored width decides, and only the
indexing path may rebuild", plus the migration. @jimmyken is credited on the
commit as co-author; #21 is closed in favour of this.