fix(ui): stale data modal incorrectly shown when user saves their own document (#15933)

# Overview

Fixes a race condition where the "Document Modified" modal incorrectly
appears after a user types and saves their own document.

## Key Changes

- Added `saveCounterRef` to track in-flight saves, incremented in the
Form's `onSubmit` callback
- Added a failing e2e test that reliably reproduces the race condition

## Design Decisions

The stale data check compares `originalUpdatedAt` (sent with the
form-state request) against the current DB `updatedAt`. If a save
happened while a form-state request was in-flight, the DB timestamp
advances and `isStale` returns true — correctly for *another user's*
save, but incorrectly for *your own*.

The fix captures the save counter at the start of each form-state
request and skips the stale modal if a save was initiated during that
window. The counter is incremented in `onSubmit`, which fires
synchronously before the PATCH is sent. This guarantees the counter is
already incremented before any form-state response could see our own
save's `updatedAt` as stale — closing the race window entirely.

The two-user scenario is unaffected: the counter is per-instance, so
another user's save doesn't increment the local counter and the modal
still appears correctly.