fix(cli): route to a running server only when it serves the resolved store (#1445)

[ajianaz]

What

• uteke-core: store_identity(path), the first 16 hex digits of the SHA-256 of a store's canonical path (trailing slashes trimmed when the directory does not exist). Two spellings of one directory give the same id.
• uteke-server: new LAB route GET /store returning {"id": "<id>"} for the store the server serves (ReqCtx.store_id, set from the home directory at startup). Registry row (writes: false), handler and HANDLERS row added. The path itself is never returned. It needs the normal token when auth is on, and a read-only token may call it.
• uteke-cli: server_serves_store(url, store). Before routing to a loopback server the CLI asks GET /store and compares the id with the store it resolved (UTEKE_HOME, --store, uteke.toml). A mismatch runs the command locally with a warning on stderr. A 404 (older server), 401, timeout (500 ms), a body that is not an id, or a non-loopback server keeps the previous routing.
• docs/api-reference.md and docs/core-contract.json regenerated: /store appears in the lab list only, core is unchanged. CHANGELOG entry added.

Why

UTEKE_HOME=/tmp/iso uteke remember ... with [server] enabled = true was sent to the running server and landed in the server's store, which defeats the isolation #1105 promised. The CLI had no way to know which store a server serves. The owner approved the design on 2026-10-16: a LAB route with a token (no CORE change, so no cloud contract issue), returning an id instead of a path so nothing about the host layout is exposed. Closes #1445.

Testing

• New tests: core store_identity (spellings, different dirs, a pinned value checked independently with shasum), server GET /store (200 with the id for a read-only token, 401 without a token, POST refused), CLI server_serves_store against a stub HTTP server (same store routes, another store does not, 404/401/non-JSON/refused/non-loopback keep routing).
• cargo test --workspace and cargo clippy --workspace --all-targets -D warnings are clean; cargo run -p docgen output is committed.
• End to end with a real uteke-serve on store S and a client on store H ([server] pointing at it), the reproduction from the issue: before, the memory landed in S; now it lands in H (db_count: 1) and S stays at 0 with a warning on stderr. A client with UTEKE_HOME=S still routes through the server.

[github-actions]

🔍 Cora AI Code Review

✅ No issues found. Code looks good!

---

Review powered by cora-code · BYOK · MIT

[ajianaz]

Merging with the two code-scanning alerts still listed: both are anchored to the earlier commit 998b1cb (no analysis was uploaded for the later head). #786 (probe sends no token) was checked against an auth-enabled uteke-serve: with UTEKE_AUTH_TOKEN the guard works, without it the routed command is refused with 401 and nothing lands in the wrong store; the probe uses build_client and a test now pins the Authorization header. #787 flagged the literal test URL 192.0.2.1, which no longer exists. Cora on the head commit: no issues found, 15/15 checks.