fix (issue-112): strip launching shell state from terminal env

[3NiTiN3]

Fixes #112

What happens

The integrated terminal inherits the environment of whatever process started SideX. Launched from a terminal, that environment carries the launching shell's session state into every shell SideX spawns; launched from the desktop menu, it starts from the clean session environment. CommandBuilder seeds its environment from std::env::vars_os(), and the env map the frontend sends is built from the same process environment, so nothing filtered it on either path.

On the reporter's system the variable that matters is VTE_VERSION, exported by gnome-terminal. The spawned login shell reads /etc/profile, which sources /etc/profile.d/*.sh in alphabetical order:

1. starship.sh sets PROMPT_COMMAND="starship_precmd".
2. vte-2.91.sh runs after it and, with VTE_VERSION present, appends to PROMPT_COMMAND when it is a bash array and overwrites it otherwise. Starship leaves it a plain string, so the overwrite wins.
3. ~/.profile then sources ~/.bashrc, which sets a static PS1 and the user's aliases.

The aliases land and the prompt does not, which is exactly what was reported. It is bash-only because that assignment is vte.sh's bash branch and neither fish nor pwsh reads /etc/profile, and it needs a system-wide starship, because starship initialised from ~/.bashrc runs after profile.d and wins. Confirmed against the reporter's own /etc/profile.d/vte-2.91.sh and their diff of the two environments, not a reconstruction.

The change

drop_session_scoped_env removes session-scoped variables from the CommandBuilder immediately before spawn, which is late enough to also cover the env map the frontend re-applies.

The list separates two things:

• VTE_VERSION is the confirmed cause of Terminal: Starship.rs custom prompt not set in Bash when SideX started from CLI #112. It is also wrong to forward on its own terms: this terminal renders through xterm.js, not VTE, so advertising a VTE version additionally makes bash emit VTE title sequences at every prompt.
• The rest is defensive hygiene for the same class of leak, found while investigating and each checked against a real shell, but none of them is what happens in Terminal: Starship.rs custom prompt not set in Bash when SideX started from CLI #112. PS0-PS4, PROMPT_COMMAND, RPROMPT, starship's runtime variables, SHLVL, OLDPWD, _, BASH_ENV, ENV, exported bash functions, and the VS Code shell-integration markers. The bash-preexec and ble.sh detection names are the notable ones: if __bp_imported, bash_preexec_imported, precmd_functions or preexec_functions is present without bash-preexec actually being loaded, starship's init takes its bash-preexec branch and registers into arrays nothing ever runs, so the prompt is never drawn while the rest of .bashrc still applies. Reproduced by presetting any one of them.

Configuration the user opted into is deliberately kept: STARSHIP_CONFIG, STARSHIP_CACHE, PATH, HOME, SHELL, TERM. Stripping those would break the prompt from the other direction.

A menu launch has none of these variables, so the filter is a no-op there and both launch paths now hand the shell the same clean slate.

Verification

• Three unit tests covering the matched names, the kept configuration, and removal against a real CommandBuilder: cargo test --lib commands::terminal passes, 3 passed / 0 failed.
• cargo fmt --check reports no diff for this file.
• cargo clippy --no-deps --all-targets -- -D warnings produces no diagnostics for this file.

Note for reviewers: the clippy gate is currently failing repo-wide for unrelated reasons on clippy 0.1.98 (274 findings in sidex, one in sidex-text), which looks like toolchain drift given there is no rust-toolchain.toml pin. Worth a separate pass.