Prevent parallel frontend edits from overwriting each other

[yxlyx]

Source issue: https://github.com/yxlyx/lawplain/issues/61

Problem

Parallel frontend editing across multiple tabs, sessions, or agents can silently overwrite newer changes.

If one context reads an older version of a file and later writes it back after another context has already saved newer changes, the stale write can remove or rewrite features that were added in the meantime. This forces users to reimplement lost work.

Expected behavior

A tab, session, or agent must not silently overwrite a file that has changed since it was read.

When saving or replacing a file, the editor/code-generation flow should verify that the current file still matches the version/hash/revision that was originally read. If it does not match, the write should be blocked or converted into an explicit conflict flow.

Possible approaches

• Track the file version, hash, or revision read by each tab/session/agent.
• Before writing, compare the current file state against that base revision.
• If the file changed, block the write and show an actionable conflict message.
• Optionally support per-file locking/claiming while a file is actively edited.
• If locks are implemented, release them on completion, session close, cancellation, or heartbeat timeout.
• Agent/code-generation flows should validate that files have not changed since being read before doing replacement or rewrite operations.

Acceptance criteria

• Stale writes to the same file are blocked or require explicit conflict resolution.
• A stale write cannot silently remove features added by another tab/session/agent.
• Users receive an actionable message explaining that the file changed and what to do next.
• Parallel editing of different files remains allowed.
• If file locks are implemented, they are per-file and have safe expiry behavior.
• Agents and code-generation flows validate that files have not changed since they were read before replacing or rewriting them.

Regression scenario

1. Tab A opens a frontend component.
2. Tab B opens the same component from the same or older state.
3. Tab A adds Feature A and saves.
4. Tab B, still based on the older state, adds Feature B and saves.
5. Expected: Tab B is blocked or shown a conflict, and Feature A remains unless the user explicitly chooses to overwrite it.
6. Actual bug to prevent: Tab B silently overwrites the file and removes Feature A.