Sync the self-hosting stack

CHANGELOG.md

@@ -11,35 +11,28 @@ cannot be published without its entry.
 
 ## 2026-08-31 — Jarvis can wake itself up, knows what day it is, and can read the web `api 0.102.0` `web 0.125.0` `browser 0.1.0`
 
-**The schema step stops once on the way in — see the upgrade note below.** It is the same guard as
-`api 0.101.0`, tripped by a different change.
+**The schema step is uneventful for almost everyone** — unlike `api 0.101.0`. Read the upgrade
+note below only if you created a scheduled task through the Settings screen this afternoon.
 
-### Taking this build: the schema step stops once again
+### Taking this build: what the schema step does
 
-Same guard as `api 0.101.0`, tripped by a different change — and for the same reason it is harmless
-here. Reshaping scheduled tasks around the conversation drops the columns the old organization-wide
-version needed, and the guard refuses a drop without being told to:
+Reshaping scheduled tasks around the conversation drops the columns the organization-wide version
+needed. **On almost every instance this passes without stopping**, and that is not luck: the guard
+refuses a column drop when the table has rows in it, and `Schedule` is empty on every instance that
+upgraded from `0.100.0` or earlier — the table only existed from `0.101.0`, published a few hours
+before this. Watched on our own instance: dropped six columns and an enum, no warning, no
+intervention.
 
-```
-⚠️  There might be data loss when applying the changes:
-  • The `Schedule` table will lose columns: kind, autonomy, toolName, assetId, …
-Error: Use the --accept-data-loss flag …
-```
-
-**Nothing of yours is in those columns.** They existed only in `api 0.101.0`, which was published
-this afternoon, and only a wake-up created through the removed Settings screen could have filled
-them. Check before you take our word for it:
+**Read the rest of this only if that table is not empty**, which means you created a scheduled task
+through the Settings screen that this release removes:
 
 ```sql
 SELECT count(*) FROM "Schedule";
 ```
 
-If that is 0 — which it is on every instance that upgraded straight from 0.100.0 or earlier — the
-migration cannot lose anything. If it is not 0, those rows are wake-ups you created today and they
-will be dropped; note down what they were before you continue, and recreate them by asking Jarvis
-inside the conversation you want them in.
-
-Then let it through **once**, and put the guard back:
+If it returns anything but 0, the migration will refuse and print what it would destroy. Those rows
+are wake-ups you made today; note down what they were, then let it through **once** and put the
+guard back:
 
 - **compose** — set `SCHEMA_ACCEPT_DATA_LOSS=true` in `.env`, `docker compose up -d`, wait for the
   api, then remove the line. Leaving it set would let a genuinely destructive change through
@@ -47,6 +40,9 @@ Then let it through **once**, and put the guard back:
 - **Kubernetes** — set the same variable on the `jarvis-migrate` Job, run it to completion, then take
   it off. The api pods keep serving the old build while the Job fails, so there is no outage.
 
+Then recreate them by asking Jarvis inside the conversation you want them to run in — which is where
+they now live.
+
 ### Scheduled tasks are now part of a conversation
 
 `api 0.101.0` shipped these a few hours ago as an organization-wide screen, and that was the wrong