docs: bump VERSION to 0.18.5.0, CHANGELOG + TODOS entry

User-facing changelog leads with the problem: /checkpoint silently
stopped saving because Claude Code shipped a native /checkpoint alias
for /rewind. The fix is a clean rename to /context-save +
/context-restore, with the second bug (restore was filtering by current
branch and hiding most recent saves) called out separately under Fixed.

TODOS entry for the deferred lane feature points at the existing lane
data model in plan-eng-review/SKILL.md.tmpl:240-249 so a future session
can pick it up without re-discovering the source.

TODOS.md

@@ -1,5 +1,23 @@
 # TODOS
 
+## Context skills
+
+### `/context-save --lane` + `/context-restore --lane` for parallel workstreams
+
+**What:** Let users save and restore per-workstream (lane) context independently. On save: `/context-save --lane A "backend refactor"` writes a lane-tagged file. Or `/context-save lanes` reads the "Parallelization Strategy" section of the most recent plan file and auto-generates one saved context per lane. On restore: `/context-restore --lane A` loads just that lane's context. Useful when a plan has 3 independent workstreams and the user wants to pick one up in each of 3 Conductor windows.
+
+**Why:** Plans produced by `/plan-eng-review` already emit a lane table (Lane A: touches `models/` and `controllers/` sequentially; Lane B: touches `api/` independently; etc.). Right now there's no way to transfer that structure into resumable saved state. Users manually re-describe the scope in each window. Lane-tagged save/restore would be the bridge between "here's the plan" and "three people (or three AIs) are now working in parallel on it."
+
+**Pros:** Turns `/plan-eng-review`'s parallelization output into actionable resume state. Reduces context-loss across Conductor workspace handoffs for multi-workstream plans.
+
+**Cons:** Net-new functionality (not a port from the old `/checkpoint` skill). The "spawn new Conductor windows" part needs research into whether Conductor has a spawn CLI. Also requires lane-tagging discipline in the save step (manual or extracted).
+
+**Context:** Source of the lane data model is `plan-eng-review/SKILL.md.tmpl:240-249` (the "Parallelization Strategy" output with Lane A/B/C dependency tables and conflict flags). Deferred from the v0.18.5.0 rename PR so the rename could land as a tight, low-risk fix. Saved files currently live at `~/.gstack/projects/$SLUG/checkpoints/YYYYMMDD-HHMMSS-<title>.md` with YAML frontmatter (branch, timestamp, etc.). The lane feature would add a `lane:` field to frontmatter and a `--lane` filter to both skills.
+
+**Effort:** M (human: ~1-2 days / CC: ~45-60 min)
+**Priority:** P3 (nice-to-have, not blocking anyone yet)
+**Depends on:** `/context-save` + `/context-restore` rename stable in production (v0.18.5.0+). Research: does Conductor expose a spawn-workspace CLI?
+
 ## Browse
 
 ### Scope sidebar-agent kill to session PID, not `pkill -f sidebar-agent\.ts`

VERSION

@@ -1 +1 @@
-0.18.4.0
+0.18.5.0