[M14 foundation] Make source-edit transactions project- and frontend-aware

[Teakowa]

Parent: #127

Goal

Replace the OPY-hard-coded M9 edit-validation path with the smallest frontend-neutral, project-aware source-edit transaction contract required by current Wright semantics.

Context

crates/wright-driver/src/edit.rs currently validates edited text by forcing SourceKind::Opy and a synthetic edit.opy, while the current compiler/session owns native OPY, OSTW, and Workshop input/project semantics. M10 also introduced multi-source/version-aware rename behavior outside this original single-source validation path.

Before adding OSTW rename or agent mutation operations, Wright needs one reliable validation boundary that preserves the source kind, project graph, source identity, and overlays of the code being edited.

Scope

• Audit the existing M9 SourceEdit/EditValidation API and the M10 multi-source rename/edit result to identify the minimum shared contract that should survive.
• Introduce a source-aware edit transaction capable of carrying one or more file edits with exact ranges plus source identity/version preconditions.
• Define deterministic ordering, overlap/conflict detection, stale-source refusal, and all-or-nothing preview semantics.
• Validate the edited project using its original SessionConfig/SourceKind, project root, source graph, and native frontend rather than forcing .opy.
• Support in-memory overlays or an equivalent project overlay mechanism so validation does not require rewriting the user's real files or fabricating a misleading source kind.
• Preserve diagnostic source paths/spans/provenance from affected files through failed and successful previews.
• Keep application/writing separate from validation; this issue returns validated edits/previews and does not authorize semantic core to mutate the filesystem.
• Migrate existing OPY safe-edit regressions and M10 rename validation to the shared contract where doing so removes duplicated semantics without changing accepted behavior.
• Add focused OSTW validation fixtures proving the shared transaction infrastructure can validate edits against an OSTW project, but do not implement OSTW semantic rename here.

Non-goals

• New refactoring kinds beyond what is needed to prove the transaction contract.
• OSTW semantic rename; follows this foundation.
• Agent/tool-service mutation operations; follows this foundation.
• Whole-source reconstruction or WIR mutation.
• A general virtual filesystem/incremental compiler redesign.
• Expanding OPY/OSTW syntax.

Acceptance criteria

• Edit validation no longer hard-codes SourceKind::Opy or a synthetic edit.opy validation path.
• Single- and multi-source transactions preserve source identity/version preconditions and reject stale/overlapping/conflicting edits deterministically.
• Validation runs through the correct native frontend and project semantics for at least current OPY and OSTW evidence fixtures.
• Cross-file/project diagnostics retain the correct source path/span/provenance after applying the in-memory candidate transaction.
• Validation is atomic: an unsafe transaction returns structured diagnostics and no partially accepted mutation.
• Existing accepted OPY/M10 rename behavior remains green on the shared contract.
• No filesystem write is required to preview/validate a transaction.
• Public contracts remain source-oriented and do not expose mutable HIR/WIR internals.
• Full current CI remains green.

Relationships

• First implementation step under [M14] Validated source edits and semantic refactoring across Wright frontends #127.
• Reconciles M9 [M9] Define safe source edit and refactoring contracts #59 with the project/source correctness established by M10 [M10 correctness] Make diagnostics source-aware and dependency-reactive #72/[M10 correctness] Implement project-wide semantic rename #73 and the native OSTW session path from M13.
• Enables semantics-backed OSTW rename and agent-facing validated mutation without duplicating edit validation.

[Teakowa]

PM acceptance blocker from PR #133 verification (da89ab6): #128 is not accepted yet.

Three transaction correctness gaps remain:

1. Same-source edits are stored ascending and applied sequentially to already-modified text, so a length-changing earlier replacement shifts later original-source ranges. Apply all non-overlapping ranges against one original snapshot (descending order per source or a single-pass algorithm).
2. char_col silently clamps invalid 1-based columns (0 / past EOL) instead of refusing the malformed exact range. Same-position zero-width edits are also currently permitted without an explicit conflict/order contract.
3. When edited-project compilation fails, validate_transaction still returns preview: Some(...), contrary to the atomic validated-preview contract. The current broken-include test does not catch this because its preview assertion accepts either state.

Required regressions: same-line length-changing edits, multiline shift before a later edit, semantic rename with multiple same-line occurrences to longer/shorter names, invalid columns, zero-width conflict behavior, and failed validation => no validated preview.

Keep the current frontend/project overlay architecture; this is a bounded #128 correctness repair, not a redesign.

[Teakowa]

PM re-verification at PR #133 head 264fa43: the previously recorded #128 correctness blockers are resolved in code and focused regressions. Multi-edit ranges now apply against one original snapshot, invalid columns refuse rather than clamp, order-dependent same-position zero-width edits refuse, and compile-invalid transactions return no validated preview. The current PR head has 22/22 GitHub checks successful. #128 is implementation-accepted pending the branch/PR being merged into durable main; final M14/#132 acceptance must be rerun/recorded against the repaired head rather than the earlier da89ab6.