feat(plan): file-based revisions, free-form status, and optimistic locking

[Sayt-0]

Summary

Implements the three plan-toolset improvements from #3263: file-based plan revisions, a free-form status field, and version-based optimistic locking. The existing auto-incremented revision is reused as the version number.

New tools

Tool	Purpose
export_plan_to_file	Writes the plan content to a path and returns only metadata (never the body), so materialising a plan before editing costs no output tokens.
update_plan_from_file	Commits new content read from a file, avoiding re-sending the whole body.
set_plan_status	Sets the free-form status without rewriting the body (the plan must already exist).
get_plan_status	Reads the status and revision without fetching the body.

read_plan and list_plans now also report status; write_plan, update_plan_from_file, set_plan_status and delete_plan accept an optional last_known_revision.

Issue expectations mapped

Issue ask	Implementation
update_plan_from_file accepting a file path	update_plan_from_file tool
export_plan_to_file writing content without returning it	export_plan_to_file returns metadata only
Free-form status, no enum	Plan.Status string, no validation
Read/write status independently of the body	set_plan_status / get_plan_status (lightweight StatusView)
TUI surfaces status alongside the title	new plantool renderer on single-plan calls
Auto-incremented version per write	reuses the existing revision
Optional version guard on writes, conflict on mismatch	last_known_revision on every write tool, VersionConflictError
Reads return the version	read_plan, get_plan_status and export_plan_to_file return revision

Safety

Concern	Handling
Wrong path streams unbounded data or blocks	File reads reject directories and non-regular files (devices, named pipes) before opening, and are bounded by an io.LimitReader
Concurrent writes silently clobber each other	Optimistic-lock compare-and-set runs under the storage mutex; a conflicting write or delete never mutates state

Tests

• Plan package: status set/get/preserve, the export then edit then commit round-trip, file-read edge cases (missing, empty, directory, named pipe, oversized), conflict on every write tool, an 8-goroutine concurrency test (exactly one writer from a given revision wins, the rest conflict), and an extended cross-backend conformance suite.
• TUI: the renderer surfaces status and title and passes conflict errors through; factory routing is locked in.
• All pass with -race; lint is clean on the changed packages; the tree cross-compiles for Windows (the named-pipe test is //go:build unix).

Note for reviewers

The optimistic-lock parameter is named last_known_revision rather than the issue's last_known_version, for coherence with the existing revision field that reads already return (a caller reads revision and passes the same value back). If last_known_version is preferred, it is a small rename.

Implements #3263.