Background

In Dynomate, there are currently two ways to edit an item:

Quick Edit (context menu)
- Triggered from the row’s context menu.
- Edits are applied immediately to DynamoDB (no staging).
Inline / JSON Editor (sidebar)
- Editing directly in the table cell or in the JSON sidebar.
- Edits are staged and must be explicitly confirmed as part of a 2-step process before being written to DynamoDB.

Problem

If a user:

Makes an inline/JSON edit to an item → edit becomes staged.
Then performs a Quick Edit on the same item (instead of confirming the staged change),

The original staged operations remain in the “pending” state, even though the underlying item has changed.

This leads to:

Stale staged operations that don’t match the current item in the table.
Potentially dangerous writes if the user later confirms a staged edit that was created against an out-of-date version of the item.
Confusing UX: the staged badge / count suggests there are valid pending changes, but the table is showing newer data.

We need the staged operations to stay in sync with the state of the table, and to be automatically refreshed or cancelled when they become stale.

Staged operations sync with table refreshes/updates
- Whenever the table data is refreshed (manual refresh, batch operations, re-query, pagination change, filter change, or background refresh), Dynomate should:
  - Reconcile staged operations against the latest item data.
  - Cancel or mark as invalid any staged operations that no longer match the item’s current state.
Quick Edit should reconcile staged edits
- If a Quick Edit is performed on an item that has existing staged edits:
  - Either:
    - (Preferred) Automatically cancel the staged edits for that item, or
    - Surface a clear UX state (“Staged edits invalidated due to newer changes”) and remove them from the “to be applied” batch.
- The user should never be able to accidentally confirm an edit that was staged before a newer Quick Edit.