Model selection: support per-table models and handle model change on populated embedding tables

[dpage]

Raised by @danolivo during review of #14.

Two related concerns about pgedge_vectorizer.model:

1. Global, not per-table. The model is a single GUC applied to every table. Different datasets often want different embedding models, so a per-table (per-vectorizer) model setting would be more flexible.
2. Changing the model on an existing embedding table. If a table already has embeddings of dimension N and the model is changed to one producing dimension M, subsequent inserts will mismatch the column dimension and error. There is currently no guard or migration path.

Action: design per-table model configuration and define behaviour when the model (and therefore embedding dimension) changes for an already-populated table — at minimum a clear error, ideally a guided re-embed/migration.

Pre-existing architecture concern; not introduced by #14.

[dpage]

Correcting the second half of this issue: the guard already exists, so this ticket is entirely an enhancement rather than part defect.

src/worker.c:1512 compares the dimension the model returned against the chunk table's atttypmod before writing anything. On a mismatch it emits an actionable warning naming both dimensions:

Embedding dimension mismatch for table %s: model returned %d dimensions but table expects %d. Reconfigure pgedge_vectorizer.model or recreate the chunk table with the correct dimension.

and marks every item in the batch failed with Dimension mismatch: model=N, table=M, clearing next_retry_at so it does not retry something that cannot succeed. So there is no risk of embeddings of two different dimensions being mixed in one table, and no silent corruption; the failure is detected before any write and reported in both the log and the queue row.

What is genuinely missing is documentation. There is no mention of dimensions in configuration.md, best_practices.md or troubleshooting.md, and nothing connects "you changed the model" to "you must regenerate". recreate_chunks() is documented, but only as a way to regenerate chunks, with no indication that a model change is the situation calling for it. Someone switching from text-embedding-3-small to -3-large therefore gets a warning in the server log and a set of failed queue rows, with the docs silent on the cause and the remedy. That is being fixed separately as a documentation change.

That leaves this issue as the per-table model request on its own, which is a feature rather than a fix: today the model is one GUC applied to every vectorizer, and different datasets often want different models. Worth noting for whoever picks it up that the registry (pgedge_vectorizer.vectorizers) has no model column today, and the model is read straight from the GUC in chunking.c, hybrid_chunking.c and the provider implementations, so per-table support means threading a looked-up value through all of those rather than just adding a column.