fix(cli): make the update-notifier docs match what the code actually does

Review round 2. Three findings, all valid.

The previous commit's message claimed it had replaced `process.env.SIM_CONFIG_DIR
= undefined` with `delete` in the test teardowns. It had not: it added a comment
explaining why the assignment is wrong and left the assignment in place, so the
teardown still stored the literal string "undefined". Both files now actually
delete it. The same pattern exists in profile.test.ts and configure.test.ts,
which predate this branch and are left alone.

Two documentation claims were stronger than the implementation.

"At most once a day" is only true with a writable `~/.sim`. The pace lives in a
timestamp file, so a read-only home in a container - or a `~/.sim` left
root-owned by an earlier sudo install - means the pace cannot be remembered and
the check runs per command. That was already noted in a code comment; it is now
in the docs where users read it, along with the fact that it stays bounded by
the same one-second timeout.

"The tag it was installed from" described behaviour that does not exist. The
check only ever queries `latest`, because prerelease installs return before any
request. Both docs now say that plainly instead of implying the CLI can ask
about the staging or dev channel.

Author: mzxchandra

apps/docs/content/docs/cli/configuration.mdx

@@ -124,8 +124,9 @@ shared profile cannot also set its own endpoint or API key.
 ## Update notices
 
 At most once a day, and only when stderr is a terminal, the CLI asks
-`registry.npmjs.org` which version is published under the dist-tag it was
-installed from. When a newer one exists it prints a single line on stderr naming
+`registry.npmjs.org` what is published under the `latest` tag. Prerelease
+installs are skipped entirely rather than compared against their own channel,
+so a `-preview` or `-dev` build is never told to upgrade. When a newer one exists it prints a single line on stderr naming
 both versions and the command that upgrades:
 
 ```
@@ -154,6 +155,12 @@ The notice is skipped entirely when:
   deliberately trails the published one
 - the installed version is a prerelease from the `staging` or `dev` channel
 
+The once-a-day pace comes from a timestamp in `~/.sim/update-check.json`. If
+that file cannot be written — a read-only home in a container, or a `~/.sim`
+left root-owned by an earlier `sudo` install — the pace cannot be remembered,
+so the check runs once per command instead of once per day. It stays bounded by
+the same one-second timeout, and `SIM_NO_UPDATE_CHECK=1` still turns it off.
+
 Set `npm_config_registry` to ask a mirror instead; its path and query are
 preserved, so a token-authenticated Artifactory or Nexus base works.
 

packages/sim-cli/README.md

@@ -261,9 +261,11 @@ The main environment variables are:
 | `SIM_DEBUG` | Print request diagnostics to stderr |
 | `SIM_NO_UPDATE_CHECK` | Turn off the update notice |
 
-Once a day, at an interactive terminal, `sim` asks `registry.npmjs.org` which
-version is published under the tag it was installed from, and prints one line on
-stderr when a newer one exists. It sends nothing but its own version and never
+Once a day, at an interactive terminal, `sim` asks `registry.npmjs.org` what is
+published under the `latest` tag and prints one line on stderr when a newer
+version exists. Prerelease installs are skipped entirely. The once-a-day pace
+depends on a writable `~/.sim`; without one the check runs per command, still
+bounded by a one-second timeout. It sends nothing but its own version and never
 your Sim API key. If `npm_config_registry` points at a private mirror, the check
 goes there instead and carries whatever credentials that URL embeds, since the
 mirror would otherwise refuse it. Set `SIM_NO_UPDATE_CHECK=1` to turn it off;