Trim the settings pasted into the desktop setup screen

[kevin9327]

What this changes

Four values are typed or pasted on the desktop setup screen. The screen decides whether to enable
its button on the trimmed string:

disabled={busy || apiKey.trim() === "" || modelKey.trim() === "" || root.trim() === ""}

and then sends the untrimmed one:

await invoke("start_stack", { root, apiUrl, gatewayWsUrl: wsUrl, apiKey, openaiApiKey: modelKey });

On the Rust side exactly one of them is rescued:

if !model.openai_api_key.trim().is_empty() {
    env.insert("OPENAI_API_KEY".into(), model.openai_api_key.trim().to_string());
}

env.insert("INTELLIGENCE_API_URL".into(), intelligence.api_url.clone());
env.insert("INTELLIGENCE_GATEWAY_WS_URL".into(), intelligence.gateway_ws_url.clone());
env.insert("INTELLIGENCE_API_KEY".into(), intelligence.api_key.clone());

So OPENAI_API_KEY survives a stray space and the other three carry it into .env.

What that costs

Selecting a token in a provider's dashboard picks up a trailing space more often than not, and a
credential is the one kind of value nobody eyeballs after pasting — it is a wall of characters in a
password field.

The result is a deployment that starts cleanly and then fails at the first request, with the
provider rejecting a key that looks right in .env and a Bot saying it cannot answer. Nothing in
that chain names the space. The trimming already applied to the model key is there for exactly this
reason; this extends it to the three values entered beside it.

Fix

compose trims the three intelligence values the way it already trims the model key. Nothing else
moves: a value with nothing around it is byte-identical, and the "blank means leave it out
entirely" rule for the model key is untouched.

Done here rather than in the screen deliberately. start_stack is a Tauri command and this is the
boundary where the string becomes a setting, so trimming here holds whatever called it.

Where it runs

• New state that outlives a request? None. A pure function over its arguments.
• What happens on the second replica? Not applicable: the shell runs on one machine. The
  .env it writes is what every replica of the deployment then reads, so the fix reaches all of
  them by reaching the file.
• Anything serialised? No.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? None.

Boundary and audit

• Every acting call still goes through the gateway: no server path is touched.
• New refusals and new failures each write a row: not applicable — this runs before a deployment
  exists.
• Nothing new is trusted from the client: strictly less. The value is normalised at the command
  boundary rather than taken as sent.

Changelog

• A line in CHANGELOG.md under Unreleased.

Tests

Two in desktop/src-tauri/src/env.rs:

• the three intelligence values are trimmed, and the model key beside them still is — the assertion
  that pins them as consistent rather than each separately
• a value with nothing around it is untouched

Against main the first fails:

  left: "  https://api.example  "
 right: "https://api.example"

How I tested

Windows 11. cargo test --lib in desktop/src-tauri is 72 passed, 0 failed, up from 70 by the two
new tests. cargo fmt --all -- --check and cargo clippy --lib are clean. The crate has no
rust-toolchain.toml, so I built it with the 1.98.0 toolchain installed here.

I left root alone: it is a directory chosen through a picker rather than pasted, and trimming a
path is a different question from trimming a credential. Happy to take it in this PR if you would
rather they moved together.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.