fix(web): re-apply the write that settles after an overlapping one failed

Review round 5 on #2091, both findings.

The other overlap order was still wrong. Write 1 (`true`) is in flight
when write 2 (`false`) fails, so the rollback resolves to the stale
entry's `false` — correct at that instant, nothing had landed. Write 1
then lands `true` and only touched refs, so if its own list reload had
failed too, no render would ever correct the UI or the live client while
disk held `true`.

Writes now report both outcomes: `landed` returns whether this write is
the settled state for its server — recorded, with nothing later still in
flight — and `failed` takes a write out of flight so an earlier one that
lands afterwards settles. The toggle re-applies the settled value to the
override and the client, gated on its server still being active.

Serializing per server was the alternative and was not taken: it makes
the modal's debounced saves queue behind each other and changes the write
path to fix a UI-reconciliation concern, and it still could not order two
requests already in flight.

The override reset also moves from a `useEffect` to `useValueChange`,
which is what this repo requires for resetting state from render data —
the entry is referentially stable between reads, and keying on it alone
subsumes the persisted boolean and the server id.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UL9retfvAXRgvi6EWk4SY4
Signed-off-by: cliffhall <cliff@futurescale.com>

clients/web/src/hooks/useLastPersistedSettings.test.tsx

@@ -149,6 +149,35 @@ describe("useLastPersistedSettings", () => {
     expect(api.resolve("A")).toBe(newest);
   });
 
+  it("reports settled only for the last write issued", () => {
+    // The flag is what tells a caller it is safe to re-apply the value to the
+    // UI: while a later write is still in flight, that write will describe disk
+    // when it reports, and re-applying now would fight it.
+    const { api } = harness([entry("A", settings())]);
+    const first = api.begin("A");
+    expect(first.landed(settings({ paginatedLists: true }))).toBe(true);
+    const second = api.begin("A");
+    const third = api.begin("A");
+    expect(second.landed(settings({ paginatedLists: false }))).toBe(false);
+    expect(third.landed(settings({ paginatedLists: true }))).toBe(true);
+    // A superseded straggler is neither recorded nor settled.
+    expect(second.landed(settings({ paginatedLists: false }))).toBe(false);
+  });
+
+  it("treats an earlier write as settled once the later one has failed", () => {
+    // The order that leaves the UI wrong: the later write fails first, rolling
+    // the UI back to a baseline the earlier write then replaces on disk. Once
+    // the failed write stops counting as in flight, the earlier one settles and
+    // its caller can re-apply the value.
+    const { api } = harness([entry("A", settings())]);
+    const first = api.begin("A");
+    const second = api.begin("A");
+    second.failed();
+    const written = settings({ paginatedLists: true });
+    expect(first.landed(written)).toBe(true);
+    expect(api.resolve("A")).toBe(written);
+  });
+
   it("does not let a straggler resurrect a record a fresh read dropped", () => {
     // The high-water mark outlives the record, so an earlier write reporting
     // after `resolve` invalidated things cannot reinstate a superseded value.