docs: name a production os serve, not os start, in the no-secret refusal; restate the 18.0 upgrade lead

os start always supplies an auth secret (it generates and persists one on
first run), so only a production os serve meets the refusal. 18.0 is not the
first release with an operator step on an existing database; it is the first
that refuses to serve one until the step has run. The amended ae6bd1a entry's
closing heading becomes What else holds.

Co-authored-by: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fo7n3y4No4WWYt32KDXjER

Author: claude

content/docs/releases/v18/index.mdx

@@ -49,12 +49,14 @@ ceremony**, `os migrate organization-ownership` (ADR-0131 D10).
   ceremony upgraded, under the same prerequisites as 17.x: the enterprise
   `@objectstack/organizations` runtime and `OS_PLATFORM_OWNER_EMAIL`. The
   18.0 pre-releases refused them; 18.0.0 does not.
-- **A production server needs an auth secret.** A production `os serve` /
-  `os start` whose stack enables auth and which resolves no `OS_AUTH_SECRET` is
-  refused before any plugin starts: with no AuthPlugin, no caller can
+- **A production `os serve` needs an auth secret.** A production `os serve`
+  whose stack enables auth and which resolves no `OS_AUTH_SECRET` is refused
+  before any plugin starts: with no AuthPlugin, no caller can
   authenticate and every row the boot wrote would have no owner. Set the
   secret, or serve without the data API (`--no-server`). `os dev` and
-  `os serve --dev` use a development fallback and need none.
+  `os serve --dev` use a development fallback and need none, and `os start`
+  generates an auth secret on its first run and persists it to
+  `<home>/auth-secret`.
 
 The step-by-step is [Upgrading to 18.0](/docs/upgrading#upgrading-to-180), and
 every flag is in

content/docs/upgrading.mdx

@@ -335,8 +335,8 @@ documentation](/docs/deployment/cli).
 
 ## Upgrading to 18.0
 
-18.0 is the first release that requires an operator step on an existing
-database. [ADR-0131](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0131-total-organization-ownership-no-null-organization-id.md)
+18.0 refuses to serve an existing database until an operator step has run on
+it. [ADR-0131](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0131-total-organization-ownership-no-null-organization-id.md)
 makes organization ownership total, and the rows a 17.x database holds have to
 be given their owners before an 18.0 server serves them. That is the
 **organization-ownership ceremony**, `os migrate organization-ownership`.
@@ -378,9 +378,11 @@ in 18.0 on a fresh install and on a database the ceremony upgraded. On a walled
 database, a customized copy of a declared webhook or sharing rule blocks its
 step and names the row.
 
-**A production boot needs an auth secret.** A production `os serve` / `os start`
-whose stack enables auth and which resolves no `OS_AUTH_SECRET` is refused before
-any plugin starts, so set the secret before you start 18.0.
+**A production `os serve` deployment needs an auth secret.** A production
+`os serve` whose stack enables auth and which resolves no `OS_AUTH_SECRET` is
+refused before any plugin starts, so set the secret before you start such a
+deployment on 18.0. `os start` is not affected: it generates an auth secret on
+its first run and persists it to `<home>/auth-secret`.
 
 What the plan lists, how a blocked row is resolved, and every flag are in the
 command's reference:

packages/cli/CHANGELOG.md

@@ -170,7 +170,7 @@
   - **`os migrate organization-ownership` runs** and upgrades a database 17.x or an 18.0 pre-release (`18.0.0-next.*`) created (12d1476 above). A v18 server refuses such a database at boot and names the command. Start 18.0.0 against it once (the boot is refused), take a backup, run `os migrate organization-ownership --out plan.json`, review the plan, run `os migrate organization-ownership --apply --plan-file plan.json --backup-taken`, then start the server again. A deployment served as a development boot (`os dev`, `os serve --dev`, for example a local one with no `OS_AUTH_SECRET`) passes `--dev` to both commands, as the refusal `os serve --dev` prints names it. `os dev` runs the ceremony itself for a local SQLite development database.
   - **`os serve` (and so `os dev` and `os start`) boots `OS_TENANCY_POSTURE=group` or `isolated`, and `OS_MULTI_ORG_ENABLED=true`** (fc34d00 above), on a fresh install and on a database the ceremony upgraded.
 
-  **What stays as it was.** A fresh install boots under every tenancy posture and writes its birth marker, so it never needs the ceremony. Kernel-level boots (`@objectstack/verify`'s `bootStack`, embedded hosts) still accept every posture.
+  **What else holds.** A fresh install boots under every tenancy posture and writes its birth marker, so it never needs the ceremony. Kernel-level boots (`@objectstack/verify`'s `bootStack`, embedded hosts) still accept every posture.
 - 78652c0: feat(cli,plugin-sharing)!: in the 17 → 18 ownership ceremony, a row whose owner cannot be derived blocks certification, and a declared-rule mirror's grants are renamed only onto a rule plugin-sharing serves
 
   Clause-②: yes (narrowing)