Replace the desktop .env banner instead of stacking another one

[kevin9327]

What this changes

The desktop shell's .env grows by two lines on every start, forever.

write keeps the lines it did not write — which is the right rule, and its own header comment
matches it:

if key.is_empty() || line.trim_start().starts_with('#') || !owned.contains_key(key) {
    out.push_str(line);   // the previous banner is a comment, so it is kept
}
…
out.push_str("\n# Written by OpenBot Desktop. Anything else in this file is left alone.\n");

So the old banner is preserved and a new one is appended beside it.

Measured

Five starts, same settings:

start 1: 4 lines, 1 banners, 1 blank lines
start 2: 6 lines, 2 banners, 2 blank lines
start 3: 8 lines, 3 banners, 3 blank lines
start 4: 10 lines, 4 banners, 4 blank lines
start 5: 12 lines, 5 banners, 5 blank lines

and the file itself:

# Written by OpenBot Desktop. Anything else in this file is left alone.

# Written by OpenBot Desktop. Anything else in this file is left alone.

# Written by OpenBot Desktop. Anything else in this file is left alone.

# Written by OpenBot Desktop. Anything else in this file is left alone.

# Written by OpenBot Desktop. Anything else in this file is left alone.
KEY_ENCRYPTION_KEY=abc=
SERVER_PORT=3000

Nothing breaks — Compose reads the settings fine. It is the file a person opens when they want to
add HTTPS_PROXY or check which port the server is on, and after a few weeks of use the thing they
came to read is under a wall of repeated banners. The existing test
rewriting_replaces_its_own_settings_rather_than_appending_them_twice covers the settings, which is
why this was not caught: it is the banner that repeats, not the settings.

Fix

The banner is a constant, and the preserve pass recognises it as the shell's own rather than as a
line somebody else wrote. The blank lines the removed banners leave behind go with them, so the
separator stays one blank line rather than one per start.

Comments somebody else put in the file are untouched — that is the point of the rule and it is what
the second test pins.

Where it runs

• New state that outlives a request? None. This is the desktop shell writing a file on one
  machine.
• What happens on the second replica? Not applicable: the shell runs on a person's own
  computer. The .env it writes is what the replicas later read, and it now says the same thing
  on the fiftieth start as on the first.
• Anything serialised? No. Same single std::fs::write as before.
• 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: nothing new is read at all.

Changelog

• A line in CHANGELOG.md under Unreleased.

Tests

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

• five starts leave one banner and a file the same length as after the first
• a comment somebody else wrote is still kept across two starts, and kept once

Against main the first fails with left: 5, right: 1.

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.

[chatgpt-codex-connector]

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