docs(Update): correct which update legs work offline

[hifiguy]

Problem

Workflows/Update.md's Network unreachable branch tells the operator to
"stop after re-running the additive legs that work from the on-disk skill
(steps 4–6)", and names step 3's overlay as the one leg that needs a fetched
payload.

Steps 4 and 5 don't work offline either — and the same sentence explains why,
one clause later: on an installed system install/ is bootstrap-only.

• Step 4, InstallHooks.ts, reads install/hooks/hooks.json
• Step 5, ScaffoldUser.ts, reads install/USER/

Neither path exists in a bootstrap-only payload, so both exit ok: false.
Step 6, ActivateImports.ts, is the only leg that actually runs — it edits
CLAUDE.md and needs no payload.

Reproduction

Clean-room, against the shipped skill only — no install required. Extract the
v7.40.4 release, point --skill-root at the installed copy it ships
(LifeOS/install/skills/LifeOS, whose install/ holds only the five bootstrap
files), and --config-root at a scratch dir containing just a CLAUDE.md
copied from install/CLAUDE.template.md:

InstallHooks.ts    → {"ok":false,"error":"payload hooks.json not found at
                      <skillRoot>/install/hooks/hooks.json"}
ScaffoldUser.ts    → {"ok":false,"error":"template USER not found at
                      <skillRoot>/install/USER"}
ActivateImports.ts → {"ok":true,"dryRun":true,"wouldActivate":[],"wouldSkip":[...]}
OverlaySystem.ts   → {"ok":false,"blockers":["payload at <skillRoot>/install is
                      bootstrap-only (no system trees: hooks, skills, agents,
                      LIFEOS/TOOLS, ...)"]}

Three of the four steps refuse; the doc predicts only one. Step 6 is the sole
survivor, and only because it reads CLAUDE.md rather than the payload.

Why it's worth fixing

The offline branch currently sends the operator into two hard failures with no
warning that they're expected. OverlaySystem's refusal is explicitly
pre-labelled "expected, not a failure" — the other two aren't, so they read as
a broken install. An operator debugging that is likely to go looking for damage
that isn't there, or to start hand-copying payload files to make the steps pass,
which is how stale trees get created.

Fix

Documentation only, one line, no code change. The wording now:

• names step 6 as the only leg that works offline
• states that steps 3–5 all require the fetch
• quotes the two additional refusal messages so they read as expected behaviour

Applied to both copies of the file, which are byte-identical on main:

• LifeOS/Workflows/Update.md
• LifeOS/install/skills/LifeOS/Workflows/Update.md

Notes

No existing issue or PR covers this. The nearest neighbours — #1950
(OverlaySystem's system-tree list drift) and #1770 (copyMissing can't update
system-owned files) — are both closed and describe different mechanics.

---

GitHub: @hifiguy · Discord: SecDude2469