refactor!: simplify query and session ownership

Use Query cancellation and native mutation results instead of HTTP
registries, access epochs and copied scope state.
Keep local auth ordering and mutation identity fences.
Allow staged generated files to remain excluded from ESLint.

Backend contract: WealthLedger/backend@d698ed9

BREAKING CHANGE: drop investment stateVersion/progress/resources
from the client contract and use data/metadata readiness instead of
rewritten query status. Cross-tab auth may require re-login.

.ai/conventions/data.md

@@ -39,6 +39,10 @@ Authorization. Auth endpoints исключены из Bearer/retry middleware. R
 координируется single-flight; после `401` с `UNAUTHORIZED` возможен один retry.
 Не добавляй собственный refresh/retry loop в caller.
 
+Cookie-writing requests упорядочены только в текущей вкладке. Cross-tab auth
+synchronization не требуется; допустим reload/re-login. Web Locks и отдельные
+token stores не добавляются.
+
 Protected queries используют existing session-aware boundary; logout очищает
 session-scoped cache. Access token хранится только в памяти, refresh передаётся
 httpOnly cookie с `credentials: include`. Не сохраняй tokens в localStorage,
@@ -50,6 +54,15 @@ GET subtree; ошибка mutation не меняет generation/cache. Это о
 от обычного фонового refetch. Даже повторное сохранение того же token начинает
 новую generation; поздний ответ прежней generation не попадает в новый кэш.
 
+Отмена/reset принадлежат TanStack Query и generated queryFn с AbortSignal,
+без HTTP request registry, URL-wide latest-read counters и access epochs.
+Успешный HTTP с `data: null` остаётся query success; readiness выбирается по
+data/metadata, без подмены query status и отдельного transport state.
+Status синхронизации содержит только состояние работы. Resources читаются
+через `sync=observe` во время работы и после завершения, без hash comparison.
+Согласованность income entries/groups обеспечивает backend; frontend не
+дублирует её runtime validator.
+
 Mutations используют существующий generated client и query-key owner;
 после успеха обновляй/invalidируй только связанные данные. Optimistic update
 нужен конкретному UX и обязан иметь rollback/error behavior.