cli: UTEKE_HOME alone still routes to a running server that serves another store #1445

What

With [server] enabled = true and uteke-serve running, UTEKE_HOME=/tmp/iso uteke remember ... (no --store) is routed to the server. The server serves its own store, so the command reads and writes that store instead of /tmp/iso.

resolve_store_path says the store is /tmp/iso (#1105). Routing ignores that.

Found while fixing the same problem for an explicit --store in #1444. That PR only covers --store; UTEKE_HOME was left out of scope.

Why

#1105 made UTEKE_HOME select the database so that an "isolated-looking" invocation cannot touch the default (often production) store. Server routing still breaks that promise.

Possible fix

• Route only when the store the CLI resolves is the store the server serves.
• Today the CLI cannot know which store the server serves. Options:
  • expose the store identity on an authenticated endpoint, or
  • treat a UTEKE_HOME that differs from the config's default store like --store in fix(cli): an explicit --store never routes through a running server #1444.

Note: UTEKE_HOME also selects the config file, so the "default store" comparison used in #1444 always matches here. It needs a different signal.

Testing

Reproduce:

1. Run uteke-serve with UTEKE_HOME=S on a temp port.
2. Run the client with UTEKE_HOME=H and H/uteke.toml containing [server] enabled = true for that port.
3. uteke remember x lands in S, not H.