Preserve unsaved React settings edits across save notifications

Problem

The React settings UI updates its saved baseline by observing a success message. Because that effect also depends on live field values, any edit made while the five-second success notice remains visible becomes part of the saved baseline even though it was never submitted. The Save button can then become disabled with unsaved settings still in the UI.

Evidence

• assets/src/js/admin/SettingsApp.jsx:51-84 posts the current fieldValues and publishes a success message after the response.
• assets/src/js/admin/SettingsApp.jsx:102-107 copies fieldValues into savedSnapshot whenever the success message is present and the field values change.
• Fields remain editable while saving is true; the state transition has no immutable submitted snapshot.
• There is no component or browser coverage for edit-during-save and edit-after-success behavior.

Scope

Make dirty-state tracking reflect exactly the values acknowledged by the server and keep later edits saveable.

Implementation plan

1. Capture an immutable submitted-value snapshot at save start.
2. Update the saved baseline only once after a successful response, using that submitted snapshot rather than a message-driven effect.
3. Choose an explicit interaction policy while a save is in flight: disable fields or allow editing while retaining those edits as dirty.
4. Remove explanatory dead/commented state-management code once the single baseline flow is in place.
5. Add UI coverage for successful save, edit during a pending save, edit during the success notice, save failure, and a disabled Save button only when current values equal the acknowledged baseline.

Acceptance criteria

• A field changed after a save request starts remains dirty unless that value was included in the successful request.
• A field changed while the success notice is visible remains saveable.
• A failed save never advances the saved baseline.
• Save state, diagnostics refresh, and the normal successful-save path retain their current behavior.

Validation

• Frontend lint and production build.
• Add focused component tests or an isolated Playwright/wp-env scenario that exercises the timing cases.
• Manual keyboard proof that the Save button re-enables after an unsaved edit.

Non-goals and risk

• Do not change the server-side settings schema in this issue.
• Do not change option names, settings payload fields, or release metadata.

Start in assets/src/js/admin/SettingsApp.jsx:51-84 and 102-107, tracing how fieldValues, savedSnapshot, saving, and the success message interact. Add focused component tests or an isolated Playwright/wp-env scenario covering successful and failed saves plus edits during pending and success states. Run frontend lint and the production build, and verify the Save button re-enables for values not included in the acknowledged request.