Desktop auto-compact editor offers 100% but backend treats GOOSE_AUTO_COMPACT_THRESHOLD >= 1.0 as disabled

**Describe the bug**

The desktop context-window popover (`ui/desktop/src/components/alerts/AlertBox.tsx`) lets users edit the auto-compact threshold on a 1–100% scale and writes `value/100` via `upsert('GOOSE_AUTO_COMPACT_THRESHOLD', ...)`. `100` is accepted, so the stored value becomes `1.0` and the popover renders **"Auto compact at 100%"**.

The backend, however, treats a threshold of `1.0` as *auto-compact disabled*, not "compact when full":

- `crates/goose/src/context_mgmt/mod.rs` (`check_if_compaction_needed`): `if threshold <= 0.0 || threshold >= 1.0 { false // Auto-compact is disabled }`
- `crates/goose/src/agents/state_machine/ops_compaction.rs` (`CompactionOperation::over_threshold`): same guard.

So the UI advertises a value whose meaning is silently "off", with no indication to the user.

Observed in the wild: a session with `GOOSE_AUTO_COMPACT_THRESHOLD: 1` in config.yaml grew to 66,770 total tokens against a believed 49,152 limit with zero compaction events in `usage_ledger`, while another session on the same provider showed manual `/compact` working fine. The UI kept displaying a plausible-looking percentage the whole time.

Related trap hit during diagnosis: env vars always beat config.yaml (`Config::get_param` checks `env::var` first), so a stale exported `GOOSE_AUTO_COMPACT_THRESHOLD` makes every config.yaml edit invisible while the popover keeps showing the env value.

---

**To Reproduce**
1. Set `GOOSE_AUTO_COMPACT_THRESHOLD: 1` (or set the desktop editor to 100%).
2. Open the context-window popover: it shows **"Auto compact at 100%"**.
3. Fill the context window past the model limit: no auto-compaction ever fires.

---

**Expected behavior**

UI and backend agree on the `1.0\|100%` semantics. Either:
- the desktop editor caps at 99% / hides or labels `>= 100%` as **"Auto compact: off"**, or
- the backend defines an explicit off-value and the UI surfaces the disabled state.

Direction: smallest fix is surfacing the disabled state in `AlertBox` (read path) plus capping the editor below 100 (write path); backend semantics stay untouched for backward compatibility.

---

**Please provide the following information**
- **OS & Arch:** macOS arm64
- **Interface:** UI (Electron), CLI confirmed same backend behavior
- **Version:** current main (worktree base `48897ccc1`)
- **Provider & Model:** openrouter – stealth/ox-alpha

---

**Additional context**

Found while investigating "context window compression stuck at 50%": root cause there was an exported `GOOSE_AUTO_COMPACT_THRESHOLD=0.5` winning over config.yaml, but it exposed this `1.0 = disabled` contract mismatch along the way. Per repo workflow, implementation waits for **Ready** status on the board.

The issue is in the mismatch between the UI component (`ui/desktop/src/components/alerts/AlertBox.tsx`) which writes a value/100, and the backend logic (`crates/goose/src/context_mgmt/mod.rs` and `crates/goose/src/agents/state_machine/ops_compaction.rs`) which treats a threshold >= 1.0 as disabled. Start by examining the AlertBox component to understand the write path and the read path for displaying the threshold. Then, look at the backend functions `check_if_compaction_needed` and `CompactionOperation::over_threshold` to see the guard condition. The fix likely involves capping the UI editor at 99% or adjusting the display to show 'off' for 100%. Run the relevant tests to ensure the UI and backend agree.

Scritto dal modello di indicizzazione a partire dal testo della issue.