[Floating-Y]

Why

Saving one knowledge base settings card invalidates the detail query. The shared synchronization effect then resets every card from the refreshed response, discarding unrelated drafts.

To reproduce:

1. Open settings for a non-default knowledge base.
2. Edit its name or description without saving.
3. Change visibility and save that card.
4. Wait for the detail query to refresh: the identity draft is lost.

What changes

Split synchronization into four effects, each depending on its card's server fields and kbId. Saving another card preserves unrelated drafts while initial loading, KB switching, saved values, and server updates to unedited cards continue to synchronize.

Keep independent PATCH payloads and query invalidation unchanged. Only the settings page and its regression test change; no API, database, dependency, or other-page changes.

Add regression coverage for draft retention, isolated requests, empty/null descriptions, saved values and status, server updates, and switching between KBs with identical server values.

The existing same-card conflict behavior remains: a server-side change to fields in a dirty card can replace that card's draft.

How it was checked

Local validation on Windows for the worktree committed as 5adc726, based on upstream/dev at c8aedf9:

• Regression tests with the original component: 4 failed, 3 passed.
• Regression tests with the fix: 7 passed.
• pnpm test: 49 files, 334 tests passed.
• pnpm build, pnpm typecheck, and git diff --check: passed.
• Build emitted the bundle-size warning for chunks over 500 kB.

Tests execute actual component input/save callbacks, mutation functions, success handlers, and query functions. Query snapshots model refreshes; browser interaction and TanStack cache integration were not tested. Backend checks were not run for this frontend-only change.

Before review

• Every commit is signed off (git commit -s)
• For changes under web/: pnpm build and pnpm test pass

[WaylandYang]

Thanks, this fixes it: each card now syncs from its own server values, and a real reload or a switch of base still starts fresh. I'll retitle the squash commit to state the behaviour. Merging.