fix: draw the API key once, and let status answer the dimensions question

Two things a user setting this up hit immediately.

The card drew `embeddingApiKey` twice. The render loop walked every entry in
FIELDS, and the secret — which is drawn by hand, as a write-only password
control — was one of them, so a second control appeared beside it: an ordinary
text input, echoing the key in clear as you typed. One key, two boxes, one of
them visible. The loop skips secrets now, and the tests count controls rather
than checking that each expected label is present, because a duplicate beside
the real control passed the old assertions.

`status` could not answer the one question a new user cannot look up: how wide
is this model? The probe that reports it was gated on every required setting
being present, so in exactly the state that needs the answer — dimensions
unset — it reported nothing and said "Missing: embedding_dimensions". It now
runs whenever the endpoint can be named (a model and a base URL), and the
status message names the width it observed:

  Missing: embedding_dimensions. The endpoint is reachable and returned 768
  dimensions, so set embeddingDimensions to 768.

The probe also tells "not set yet" apart from "set wrong", because the two have
different remedies.

Also documents both ways to read the width by hand, since a wrong value is
frozen into the index at first use and costs a full re-embed to correct.

README.md

@@ -113,6 +113,43 @@ and the tool write the same place).
 | `embeddingRequestDelay` | Milliseconds between embedding requests, for rate-limited providers. |
 | `timeoutMs` | Cooperative budget for a foreground run. |
 
+### How to find `embeddingDimensions`
+
+It is the width of the vector the model returns, and slopo **freezes it into the
+database on the first index** — get it wrong and every later run refuses with
+`Configuration mismatch` until you delete the index and re-embed. So ask the
+endpoint rather than guessing from a model name.
+
+**The tool will tell you.** `status` probes the endpoint whenever a model and a
+base URL are set — even when dimensions is not — and reports the width it
+observed:
+
+```jsonc
+{ "action": "status" }
+// → Missing: embedding_dimensions.
+//   The endpoint is reachable and returned 768 dimensions, so set
+//   embeddingDimensions to 768.
+```
+
+**Or ask it directly**, which is the same request:
+
+```sh
+# The width of the vector that comes back.
+curl -s http://127.0.0.1:11434/v1/embeddings \
+  -H 'content-type: application/json' \
+  -d '{"model":"unclemusclez/jina-embeddings-v2-base-code:latest","input":["probe"]}' |
+  python3 -c 'import json,sys; print(len(json.load(sys.stdin)["data"][0]["embedding"]))'
+
+# On Ollama, the model's own recorded width, with no inference at all.
+curl -s http://127.0.0.1:11434/api/show \
+  -d '{"model":"unclemusclez/jina-embeddings-v2-base-code:latest"}' |
+  python3 -c 'import json,sys; print(json.load(sys.stdin)["model_info"]["jina-bert-v2.embedding_length"])'
+```
+
+Both must agree. If they do not, the endpoint is truncating or padding — for
+example a server honouring a `dimensions` parameter — and it is the **returned**
+width that slopo needs, because that is what lands in the database.
+
 ### Choose the provider prefix carefully
 
 The provider prefix is not cosmetic — it selects which LiteLLM validator runs.