feat: attach scheduled workflows to existing missions - #2616

Scheduled workflows currently force mission:false, so they cannot use mission state to retain progress between fires. This adds the optional existing-mission attachment described in #815: schedule.create accepts missionId, checks the record without activating it, and persists the ID for timer, manual, and restored launches. Creation and restoration validate the ID rather than silently dropping it.

Each fire uses the existing explicit mission workflow path, state adapter, and runtime feature admission. missions.enabled:false still permits explicit attachment; disabling the missions feature rejects creation and restored execution. The association is visible in create/list/show output.

Attachment follows ordinary mission lifecycle and retention rules: closing a mission does not pause its schedule, a later fire can reactivate it, and terminal retention can remove it. Open decisions and goal-notice pause/budget settings do not gate launches. A missing mission causes failed_launch before workflow execution. Each fire resolves the store from its target cwd and current configuration/agent directory. These boundaries are documented; retention protection and recurring-specific lifecycle policies can be evaluated separately without changing the existing state API.

Mission-bound definitions use schema version 2 so older schedulers reject them instead of ignoring the ID and running without mission state. Unbound definitions remain version 1 and require no migration; the current parser rejects inconsistent version/attachment combinations.

Validation on Node 24 / Linux:

• 144 focused schedule, public API, feature-gating, schema, mission lifecycle and mission store tests passed.
• 4 tests using real async workflow workers passed with no skips: two timer fires and a fresh-session/executor restoration continue a persisted cursor (including with automatic missions disabled); unbound workflows have no state; deletion before firing and disabling missions after restoration fail before execution.
• 2 native Pi tool activation/schema-budget checks passed; npm run typecheck -- --pretty false and git diff --check passed.
• A read-only comparison with the existing main implementation verified that its reader accepts unbound v1 records and rejects bound v2 records without launching work.

Related to #815; that historical request is closed after the first schedule slice in #819. This PR implements existing-mission attachment. Recurring-specific retention and lifecycle policies remain separate design work.