feat(agent-org): persist editable Follow-up proposals for #635

[ShiboSheng]

Parent and dependency

• Parent issue: feat(agent-org): support post-completion chat and follow-up runs #635
• Depends on: feat(agent-org): add post-completion read-only Coordinator turns for #635 #643
• Delivery order: 3 of 5
• Intended PR: PR 3 — durable editable Follow-up proposals

Goal

When a post-completion Coordinator turn determines that additional execution is required, persist a bounded Follow-up proposal instead of immediately starting Workers.

The proposal is a durable work order that the user can inspect, edit inline, dismiss, or later confirm. Creating or editing it must not create a Run or start a Worker.

User behavior

The Conversation shows a Follow-up proposal containing:

• selected source Run;
• work goal;
• concrete requirements;
• optional bounded task outline;
• a clear statement that confirmation creates a new Run and fresh Workers.

The user can edit the goal, requirements, and task outline directly inside the same card. Saving increments the proposal revision while preserving the proposal identity and idempotency key.

If another Run is starting, running, or paused, the proposal may still be created and edited, but its Start action is disabled with a readable conflict explanation.

Required changes

• Add bounded agent_org_follow_up_proposals persistence with Conversation Session, source Run, originating message, status, revision, goal, requirements/task outline payload, timestamps, and optional created Run.
• Enforce one proposal identity per Conversation and originating message so model/tool retries coalesce.
• Define explicit lifecycle states for pending, accepted, dismissed, stale, and superseded proposals; Starting/launch progress belongs to the created Run, not hidden card state.
• Add Coordinator tool/API contracts to create or update a proposal only during post-completion scope.
• Add frontend API types and commands for detail, inline edit with expected revision, and dismiss.
• Bound characters, bytes, array counts, nesting, and displayed previews before persistence and across the Tauri bridge.
• Return structured stale, revision-conflict, archived-Conversation, deleted-source, and existing-live-Run states.

Invariants

• Proposal creation and editing never starts a provider, Worker, Wake, Task, Plan, Inbox, or Recovery loop.
• The selected source Run is immutable.
• Duplicate tool calls for the same originating message return the existing proposal.
• Concurrent edits use revision checking and cannot silently overwrite a newer edit.
• Dismissed, stale, superseded, or accepted proposals cannot be started as pending work.

Acceptance criteria

• A work request creates one durable pending proposal.
• A duplicate Coordinator/tool retry returns the same proposal.
• Inline edits update only user-editable goal, requirements, and bounded task outline fields.
• Concurrent stale edits return a readable revision conflict.
• Dismiss keeps a durable historical record and disables Start.
• Refresh and app restart restore the proposal and its latest revision.
• A live Run conflict disables launch but does not discard the proposal.
• Proposal operations do not change either the source Run or any Worker state.
• Oversized or deeply nested proposal payloads are rejected before SQLite writes.

Verification

• Rust persistence/state-machine/idempotency/limit tests.
• Tauri DTO serialization and revision-conflict tests.
• Frontend API/store tests for pending, edited, dismissed, stale, conflict, and restart hydration states.
• Negative assertions proving no Worker launch or old Run mutation.
• Scoped Clippy, formatting, typecheck, lint, and architecture/performance guard review.

Out of scope

• org_follow_up_start and Worker materialization.
• Starting recovery.
• Final proposal-card visual implementation and Run timeline.

Estimated change size

• Roughly 6–10 files.
• Roughly 500–900 changed lines including tests.