docs(desktop): correct browsing-data settings and trim wording

Author: waleedlatif1

apps/docs/content/docs/desktop/index.mdx

@@ -7,7 +7,7 @@ import { Callout } from 'fumadocs-ui/components/callout'
 import { Step, Steps } from 'fumadocs-ui/components/steps'
 import { Image } from '@/components/ui/image'
 
-Sim Desktop is the macOS app for your Sim workspace. Everything the web app does, it does — plus the things a browser tab cannot: a built-in browser and terminal your agents can drive, read-only access to folders you pick, and native notifications when a task finishes.
+Sim Desktop is the macOS app for your Sim workspace. Everything the web app does, it does — plus the things a browser tab cannot: a built-in browser and terminal, read-only access to folders you pick, and native notifications when a task finishes.
 
 <Image
   src="/static/desktop/sim-desktop.png"
@@ -124,7 +124,7 @@ It also shows the installed version, and the version waiting to be applied when
 
 - **Let Chat browse the web** — the master switch for the built-in browser
 - **Search suggestions**, **Theme**, **Default zoom**, and **Download location**
-- **Browsing data** — clear history, cookies, and saved sessions
+- **Browsing data** — clear cookies, site data, and cached images and files
 
 ### Terminal
 
@@ -139,7 +139,7 @@ Sim checks the deployment it is pointed at rather than a global feed. How it app
 
 **Installed in `/Applications`, signed by Sim** — what the download link above gives you. The app replaces itself. With **Automatically download updates** on, it downloads in the background and offers to restart; choose **Later** and the update applies the next time you quit. With it off, nothing downloads until you ask: **Sim → Check for Updates…** reports the available version and waits for you to choose **Download**.
 
-**Anywhere else** — outside `/Applications`, or a build not signed with a Developer ID. The app cannot replace itself, so it offers you the installer to download and swap in by hand. This is the second reason to install to `/Applications`.
+**Anywhere else** — outside `/Applications`, or a build not signed with a Developer ID. The app cannot replace itself, so it offers you the installer to download and swap in by hand.
 
 Updates come from the deployment you are connected to, so a self-hosted install controls which build its own users are offered. That control depends on the feed staying reachable: if it is not, a stable build falls back to Sim's public GitHub releases rather than stalling. See [Desktop App on Your Deployment](/platform/self-hosting/desktop).
 

apps/docs/content/docs/platform/self-hosting/desktop.mdx

@@ -25,7 +25,7 @@ Every Sim deployment exposes two public endpoints:
 | `/api/desktop/update/download` | Redirects (302) to the newest installer for this deployment's release channel |
 | `/api/desktop/update/latest-mac.yml` | The update manifest installed apps poll |
 
-Both resolve against Sim's public GitHub releases, and the installers themselves are downloaded from GitHub. Nothing is built, signed, or hosted by you: your deployment decides *which* release its clients are offered and serves the manifest, so installed apps poll your server instead of sim.ai — but they cannot be served artifacts of your own from this path, and they fall back to Sim's own feed if yours stops answering (see [What an installed app does when the feed fails](#what-an-installed-app-does-when-the-feed-fails)). To ship your own build, see [Building your own shell](#building-your-own-shell).
+Both resolve against Sim's public GitHub releases, and the installers themselves are downloaded from GitHub. Nothing is built, signed, or hosted by you: your deployment decides *which* release its clients are offered and serves the manifest, so installed apps poll your server instead of sim.ai — but they cannot be served artifacts of your own from this path, and they fall back to Sim's own feed if yours stops answering. To ship your own build, see [Building your own shell](#building-your-own-shell).
 
 Both endpoints cache their GitHub lookups for **5 minutes**, and both respond the same way when they cannot answer:
 
@@ -39,12 +39,9 @@ The Sim server needs outbound access to `api.github.com` and `github.com` for th
 
 ### What an installed app does when the feed fails
 
-Those statuses are not equivalent to a client. `404` carries a marker header the shell reads as *no update available*, and the app simply reports that it is up to date. Anything else — a `502`, a timeout, a connection or TLS failure — is treated as the feed being unavailable, and what happens next depends on the build:
+A `404` carries a header the shell reads as *no update available*, so the app reports it is up to date. Anything else — `502`, a timeout, a connection failure — means the feed is unavailable: a **stable** build falls back to Sim's packaged GitHub feed and keeps updating from the stable channel, while a **dev or staging** build skips the check, since that fallback only carries stable artifacts their bundle identity cannot install.
 
-- A **stable** build falls back to Sim's packaged GitHub feed and keeps updating from the stable channel.
-- A **dev or staging** build skips the check instead. The GitHub fallback only carries stable, production-identity artifacts, which their bundle identity cannot install.
-
-So release selection is yours while the feed answers, and reverts to Sim's stable channel when it does not. In the default configuration this is invisible — an unset `APPCONFIG_ENVIRONMENT` resolves the same `latest` release either way — but it does mean a rate-limited or unreachable deployment stops being the authority over what its users are offered, which matters as soon as your deployment serves a channel that disagrees with stable.
+Release selection is therefore yours only while the feed answers. With `APPCONFIG_ENVIRONMENT` unset both paths resolve the same release, so the fallback is invisible; it matters when your deployment serves a channel that disagrees with stable.
 
 ### Which channel your deployment serves