consolidate the worker into a single-threaded lifecycle owner

[zgeoff]

Finish making the worker a single-threaded owner of one always-present simulation: continuations become durable start intents, the start chain grows into a lifecycle mailbox, and the null-simulation states collapse. Each piece deletes more code than it adds.

Scope

• Durable start intent: replace the in-memory pending continuation with a {avatarID, scopeID, scopeType, startKey} record in the worker's preferences store, drained at reconnect and resync entry exactly like the stop intent — idempotent start keys make late or duplicate delivery safe. planResync loses its continue kind and pending-continuation input; the continue apply path and its guards go with it. A pending continuation also stops dying with the worker: today it lives in closure state and a reload loses it.
• Lifecycle mailbox: resync and continuation flows join the start chain, so lifecycle work runs strictly one flow at a time. Stops stay outside — the local halt must be instant — and their epoch bump is re-checked once at a queued flow's entry instead of after every await. Most per-await stop checks become provably dead and are deleted.
• Never-null simulation: the worker always holds a simulation ("no run" is an empty one), collapsing today's three idle representations — null, fresh-empty, activity-null — and deleting the null guards, conditional uninstalls, and just-in-case creations that each site grew around them.

Notes

• Successor to the run-stop and worker-owned-start reworks; depends on own the activity lifecycle in the worker and discipline its message concurrency #711.
• Non-goal: changing engine or resync planning semantics beyond removing the continue plan kind.
• The three scope items land in the listed order; each is independently shippable.

[github-actions]

Thanks for opening this! A few tweaks will help it move through triage — here's the checklist:

• Add a ## Player story section describing what the player perceives once this ships — every area/game feature carries a ## Player story section

  Paste-ready stub

  ## Player story
  
  <!--
  Required when the outcome is player-perceivable (every area/game issue). Second person, present
  tense: what you concretely see or feel once this ships — and what you don't experience (no dupes,
  no lost progress, no spinner spam); absences are part of the story. No implementation nouns: no
  table, field, component, or service names. Close with a one-sentence distillation of the whole
  story. Delete this section only when nothing a player can perceive changes.
  -->

Edit the issue or adjust its labels once you've worked through these, and I'll re-check and update this comment.