fix(client): resync on failed patch instead of silently corrupting the cache

[benitogf]

What & why

This PR does two things on one branch. The client fix is the deliverable; the CI repair is folded in because a red PR can't merge.

1. Resync on failed patch instead of silently corrupting the cache

When an incremental list/object update fails to apply, the JS client used to break in three ways at once: the exception escaped the WebSocket message handler (leaving the cache partially mutated), the consumer kept rendering stale state, and the subscription stayed connected on its old version so no snapshot ever arrived — the client silently stopped updating until something else forced a reconnect.

The Go client already recovers correctly (a patch error breaks the read loop and the reconnect delivers a fresh snapshot). This gives the JS client the same guarantee.

• Non-mutating, validated application — patches apply with mutateDocument: false and validateOperation: true, so a failed patch leaves the cache untouched (all-or-nothing) and an op the cache can't resolve (a positional remove/replace addressing an index a drifted cache doesn't have) throws instead of silently no-op'ing or committing a sparse […,null,{…}] array. Both are the row-drift class that caused silent divergence.
• Resync on failure — decode + patch are wrapped in try/catch. On failure the client clears cache and version and drives its existing forced-reconnect path (the same one the reconnect spec pins). With version cleared the redial carries no ?v=, so the server answers with a full snapshot and the next message delivers correct state.
• Recovery before notification — the resync runs before onerror fires, so a throwing consumer handler can't leave the subscription frozen. onmessage is never called with a corrupt or stale cache.

Normal reconnects are unchanged — they still send ?v= (the reconnect spec passes unmodified).

New patch failure resync spec: seeds 3 records, drifts the cache to [] in-page, deletes a record so the server emits a positional patch the drifted cache can't apply, then asserts onerror fired once, the redial URL carries no ?v=, and a subsequent message delivers the correct 2 survivors.

Version bumped 1.0.0 → 1.0.1. No API surface change (ooo.d.ts unchanged).

2. CI / toolchain repair (folded in — a red PR can't merge)

CI was red for a pre-existing toolchain reason unrelated to the resync diff: the workflow ran an unpinned go get github.com/benitogf/ooo on a Go 1.19 matrix, but current ooo imports the stdlib slices package (Go 1.21+), so the test harness build died with package slices is not in GOROOT.

• go.mod — go 1.19 → go 1.25; ooo pinned to 8c38013e (the merge of ooo #154, post-#150/#153/#154) so the resync is tested against the fixed server rather than the 2022 init pin. go mod tidy.
• Workflow — Go 1.25.x, node 20.x, actions bumped (checkout@v4, setup-node@v4, setup-go@v5), checkout-first. The unpinned go get is replaced with go mod download && go build ./... so CI builds reproducibly against the go.mod pin, not "whatever is newest".
• client.stats() — adapted to the fixed server's API. The new ooo serves an explorer SPA at / and moved key-listing to ?api=keys (KeysResponse{keys,…}); the old server returned stats JSON at /. stats() now pages through ?api=keys and returns {keys}, still satisfying the Stats{keys} type and preserving the old all-keys behavior.

Tests

Full suite green against the fixed server on Go 1.25 + node: 9/9 specs, 45 expects, 0 failures — including patch failure resync and keys.

Known non-blockers (out of scope, tracked)

• Regression guard for non-mutating patch application (mutateDocument: false) #1 — regression guard for the mutateDocument: false all-or-nothing property (not observable through the client's public surface; harness is integration-only).
• ooo.d.ts: onerror type does not cover the Error passed on the patch-failure path #2 — ooo.d.ts onerror type accuracy (the plan pins ooo.d.ts unchanged as an acceptance criterion).

🤖 Generated with Claude Code