feat(tasks): persist versioned project delegation briefings for execution and review #619

Problem and scope

Follow-up to #617 / #618 and the requester-approved collaborator-context roadmap. The requester explicitly asked to continue implementation and open the next Issue and PR.

Project-board execution currently forwards a browser-composed task title/description plus goal/task IDs. It does not supply a server-owned, versioned statement of the project goal, assigned task and acceptance criteria. Human review pins the completed output but cannot inspect which plan the employee actually received.

Implement phase 2a: project task delegation briefings and their inspection during human acceptance. This is a bounded part of phase two (delegation/review); AI reviewer dispatch and full task participant/dependency context remain separate later work. Reuse the existing task/session execution and human acceptance paths, without creating a second task store.

Acceptance criteria

• The project Run action sends an explicit expected workspace/plan revision. Before executing, the server resolves the existing goal/work item, validates the recipient, and includes the saved goal, assigned task and complete acceptance criteria.
• Missing/deleted tasks, stale plans, wrong recipients/workspaces and invalid request fields fail before model execution. Callers without the new opt-in retain their existing goal-association semantics.
• Persist a versioned, bounded snapshot of exactly the briefing included in input, with turn/session/task/plan identities, canonical bytes/digest and redaction facts. Reject required briefings that do not fit instead of silently dropping criteria. Required briefing and optional history share the existing context/input budgets.
• Running and terminal records preserve the snapshot across restart. Explicit retries retain their original task binding and revalidate the saved plan revision; a changed plan requires a fresh launch.
• Show the saved briefing in the personal task conversation and acceptance drawer. If the current task or criteria differ, explain the difference without rewriting past input or treating execution completion as acceptance. Historical deliveries lacking the snapshot remain reviewable with an explicit unavailable notice.
• Keep human acceptance decisions and output/version checks authoritative. No permissions, budget or acceptance status are granted by a briefing.

Dependencies and implementation

Stack the PR on #618 until phase one is merged, so the review diff contains only phase 2a. Shared request/snapshot types and validation, session IPC and route, turn assembly/storage, goal delivery projection, project launch and review UI. Update runtime packaging inventory, design documentation and changelog.

Validation

Deterministic assembly and storage tampering tests; controlled-driver API checks for saved/injected equality, stale/missing/foreign inputs, retry/restart and budgets; renderer/IPC regressions; actual browser interaction at desktop and narrow widths; repository builds/type checks/test/security checks with explicit environment limitations and CI evidence. No unsupported coverage percentage or live-provider quality claim.

Compatibility and rollback

New opt-in request and optional persisted fields. Older strict readers may reject new records: deploy matching server/IPC/renderer, retain workspace backups and use pre-upgrade data when downgrading. Do not silently retry against an older server without the requested briefing.