Feature: Interactive Plan Editor and Approval Queue in the Web Dashboard

## Summary

Add an interactive dashboard workflow for reviewing, editing, approving, rejecting, and sequencing Forge plans before execution, including support for pending approval queues across multiple running UI tasks.

## Problem / Opportunity

Forge's agentic loop includes plan generation, validation, user approval, execution, validation gates, reviewer checks, and bounce-backs. The dashboard already exposes task execution and pending prompts, but plan review is not yet a first-class visual workflow. Users working in the browser should be able to:

- Inspect generated plans before tools run.
- Edit plan steps and constraints without going back to the CLI.
- Understand which permissions will likely be requested.
- Approve, reject, or send plans back for revision.
- Manage multiple pending tasks from one approval queue.

A visual plan editor would make Forge's controllability more accessible while preserving the same runtime guarantees as the CLI.

## Proposed Feature

Build a dashboard Plan Editor and Approval Queue:

- Plan detail view with step list, dependencies, target files/modules, expected tools, and validation expectations.
- Inline editing for step text, order, mode, and constraints before approval.
- Approval queue for tasks waiting on user decisions.
- Plan diff view when the planner revises a plan after user edits or validation feedback.
- Permission forecast panel based on expected tools and side effects.
- WebSocket updates so queue status changes without reloads.

## Scope

Expected implementation areas:

- `src/core/loop.ts` and `src/core/plan-fixer.ts` for exposing editable plan state safely.
- `src/ui/task-runner.ts` for pending approval state and responses.
- `src/ui/server.ts` REST/WebSocket endpoints for plan fetch/update/approve/reject.
- `src/ui/public/` vanilla JS/CSS for the editor and queue.
- `src/types/index.ts` for serializable plan/edit/approval contracts.
- `src/persistence/tasks.ts` and events for recording plan revisions.
- Docs updates for dashboard task approval.

## Acceptance Criteria

- [ ] Dashboard users can view a pending plan before execution starts.
- [ ] Users can approve, reject, or request revision with feedback.
- [ ] Users can edit plan step text and ordering while preserving state-machine legality.
- [ ] Plan revisions are persisted as events and visible in task replay/history.
- [ ] The approval queue shows all tasks waiting for user action, including permission prompts and plan approvals.
- [ ] Permission forecasts are clearly marked as estimates and never replace actual `requestPermission` calls.
- [ ] Concurrent browser tabs receive consistent queue updates through existing watcher/broadcaster patterns.
- [ ] Unit tests cover plan update validation, illegal transition rejection, and queue serialization.

## Non-Goals

- Building a full project management board.
- Allowing dashboard edits to bypass planner validation or permission gates.
- Replacing CLI plan approval for terminal users.
- Supporting arbitrary custom DAG editing in the first version.

## Dependencies / Risks

- Plan edits must remain compatible with the task state machine in `src/persistence/tasks.ts`.
- The UI shell should remain lean and avoid adding a framework unless there is a strong justification.
- Permission forecasts may be incomplete; wording and data contracts should prevent over-trust.
- Multiple tabs editing the same pending plan need conflict handling.

## Open Questions

- Should edited plans be revalidated automatically before approval?
- Should the queue group tasks by project, mode, or age?
- Should the editor support dependency edges visually in the first version, or start with ordered steps?
- Should rejected plans remain resumable from the dashboard?