v1.0.0:3 — post-cutover seed strip

Removes the one-time `/data` snapshot from the deployed Docker image now
that the cutover from the legacy `workout-log` package is verified done
(v1.0.0:1 + :2 in production).

Dockerfile
- Drops `COPY start9/0.4/seed/data /app/seed/data`.
- Drops the `WORKOUT_BAKED_SEED_DB_PATH` env var.
- Comment block explains the rationale + how to re-seed if ever needed.

docker_entrypoint.sh
- Step 1 collapses to single-branch fallback: if /data is empty AND
  /app/prisma/data/app.db exists, copy the empty-schema fallback. The
  baked-seed branch is gone.
- Comment cross-references v1.0.0:3 for the rationale.

start9/0.4/seed/README.md rewritten to reflect historical-only status
+ how to re-seed for the rare "spin up another instance with this
history" case.

Version graph
- Adds startos/versions/v1.0.0.3.ts with empty up/down migrations and
  release notes.
- Promotes v1.0.0:3 to `current`; v1.0.0:1 and :2 move to `other` so
  hosts on either upgrade in place.

No schema changes, no data migration. /data on existing installs is
left exactly as-is. Image size drops by ~1.7MB (the snapshot size).

start9/0.4/seed/README.md

@@ -1,59 +1,60 @@
-# Seed snapshot
+# Seed snapshot (historical, post-cutover)
 
-This directory contains a one-time snapshot of `/data/` from the live
-StartOS 0.3.5 install of **Proof of Work** (`proof-of-work`). It is baked into
-the 0.4 Docker image so the first 0.4 boot comes up with your production data
-already in place.
+This directory holds the one-time snapshot of `/data/` that was used to
+cut the legacy `workout-log` StartOS package over to `proof-of-work` in
+**v1.0.0:1**. As of **v1.0.0:3** the snapshot is no longer baked into
+the deployed image — it stays here purely as a historical artifact and
+as a starting point if you ever want to spin up a new instance with
+pre-loaded history.
+
+> **Privacy:** the snapshot contains real workout history, exercise
+> records, and a bcrypt'd password hash. The repo's `.gitignore`
+> excludes `start9/*/seed/data/*.db` and `*.bak` so it never ends up in
+> version control. Do not change that.
 
 ## Source
 
 | Field | Value |
 | --- | --- |
-| Source file | `proof-of-work-2026-04-21T14-36-53-332Z.db` (user-provided backup) |
-| Exported on | 2026-04-21T14:36:53Z |
-| Exported from | StartOS 0.3.5 (aarch64) running `proof-of-work` v0.1.0.17 |
-| SQLite integrity check | `ok` |
+| Source files | `proof-of-work-2026-05-09T16-46-11-646Z.db` (latest cutover snapshot) |
+| Exported from | StartOS 0.4 host running `workout-log` v0.1.0:20 |
+| SQLite integrity check | `ok` at snapshot time |
 
-## Row counts (at snapshot time)
+The earlier `app.db.bak` file (when present on disk) is the previous
+snapshot kept around as a manual rollback; it is also gitignored.
 
-| Table | Rows |
-| --- | --- |
-| `User` | 1 (`admin@local`) |
-| `UserPreferences` | 1 |
-| `Session` | 9 |
-| `Exercise` | 164 |
-| `Workout` | 348 |
-| `SetLog` | 5720 |
-| `Equipment` | 0 |
-| `Program` / `ProgramWeek` / `ProgramDay` / `ProgramExercise` | 0 |
-| `ContentItem` / `ContentChunk` | 0 |
-| `AISuggestion` | 0 |
+## What the entrypoint did with this seed (v1.0.0:1 only)
 
-## What the seed does
+On **first boot** of v1.0.0:1, `docker_entrypoint.sh` checked for
+`/app/seed/data/app.db`. If `/data/app.db` did NOT exist AND
+`/data/.seeded` did NOT exist, it copied the snapshot into `/data/`
+and wrote `/data/.seeded` with a timestamp. On every subsequent boot
+that branch was skipped.
 
-On **first boot** of this 0.4 package, `docker_entrypoint.sh`:
+**v1.0.0:3 removed both:**
+- The `COPY start9/0.4/seed/data /app/seed/data` line in the
+  `Dockerfile`.
+- The baked-seed branch in `docker_entrypoint.sh`.
 
-1. Creates `/data/` if missing.
-2. If `/data/app.db` does NOT exist AND `/data/.seeded` does NOT exist, copies
-   everything under `/app/seed/data/` into `/data/` and writes `/data/.seeded`
-   with a timestamp.
-3. Logs which branch it took to stderr (visible in the StartOS log viewer).
+The empty-schema fallback branch (used only for brand-new sideloads
+on a host that's never had the package installed) stays.
 
-On every subsequent boot, the seed copy is skipped and the live `/data/` is
-used as the sole source of truth.
+## How to re-seed a future build (rare)
 
-## When to refresh this snapshot
+If you want to spin up another instance with this history pre-loaded
+(e.g. moving to a new StartOS host without using the in-app
+export/import flow), bring back the bake:
 
-You usually refresh the seed only if you rebuild the package **before** doing
-the first-time sideload on the 0.4 host. Once the 0.4 service is running,
-stop rebuilding with a seed — the next package release (v0.1.0:19) removes
-the seed step entirely so releases don't risk overwriting live data.
+1. Refresh the snapshot from the live host:
+   ```sh
+   ./start9/0.4/refresh_seed.sh <ssh-target>
+   ```
+2. Reintroduce the COPY line in the Dockerfile
+   (`COPY --chown=nextjs:nodejs start9/0.4/seed/data /app/seed/data`).
+3. Reintroduce the baked-seed branch in `docker_entrypoint.sh` — see
+   the comment in that file referencing v1.0.0:3 for the exact shape.
+4. Rebuild and sideload as a brand new install (the entrypoint's
+   first-boot guard will only seed if /data is empty).
 
-To refresh before first-time sideload, from the repo root:
-
-```sh
-./start9/0.4/refresh_seed.sh embassy@embassy.local
-```
-
-This SCPs the live `/embassy-data/package-data/volumes/proof-of-work/data/main/`
-files back into `start9/0.4/seed/data/` and runs an integrity check.
+For most "moving to a new instance" cases, the in-app
+**Settings → Export & import my data** flow is simpler.