[codex] fix(result-grid): preserve change tracking after no-op undo

[HanawaBanana]

Related issue

Closes #2296

Summary

• Keep result-grid cell-change tracking enabled when Revert is invoked without a selected cell.
• Pause tracking through a nested, exception-safe scope so VTable callbacks cannot permanently disable or prematurely re-enable tracking.
• Preserve CREATE, UPDATE, and DELETE bookkeeping when VTable restore or delete operations fail partway through a user action.
• Add hook-level regression coverage for no-selection revert, multi-cell revert, nested callbacks, restore failures, failed new-row revert, and mixed-row delete failures.
• Register the regression suite in Community CI.

Affected surfaces

• Frontend / Web
• Backend / API / Storage
• Database plugin / Driver
• JCEF / Desktop packaging
• CI / Build / Release
• Documentation only

Verification

• Commands and results:
  • yarn test:result-operation-record - passed all six regression scenarios.
  • yarn eslint src/blocks/SearchResult/components/ResultSetTable/hooks/useOperationRecord.tsx src/blocks/SearchResult/components/ResultSetTable/hooks/useOperationRecord.test.tsx --max-warnings=0 - passed.
  • yarn prettier --check src/blocks/SearchResult/components/ResultSetTable/hooks/useOperationRecord.tsx src/blocks/SearchResult/components/ResultSetTable/hooks/useOperationRecord.test.tsx - passed.
  • yarn test:result-tab-preferences, yarn test:execution-console, and the four test:sql-execution-* contracts kept across the workflow conflict - passed.
  • git diff --check origin/main...HEAD - passed.
  • Community CI: https://github.com/OtterMind/Chat2DB/actions/runs/30358475062
  • Security and supply-chain checks: https://github.com/OtterMind/Chat2DB/actions/runs/30358475050
• Manual verification: The focused tests synchronously exercise VTable callbacks and injected restore/delete failures, then verify tracking and operation records remain consistent.
• UI evidence: N/A - no rendered UI changes.

Risk and compatibility

• Public API or stored data: N/A; no contract or persistence changes.
• Database or driver compatibility: N/A; the behavior is database-independent.
• Network, privacy, or security: N/A; no network or data-handling changes.
• Community / Local / Pro boundary: Community result-grid hook and Community CI only.
• Backward compatibility: Successful revert/delete behavior is unchanged. Failure paths now restore tracking and leave operation records consistent with the completed table mutation.

Reviewer map

• Start here: useOperationRecord.tsx, at runWithCellValueTrackingPaused, handleRevocation, and handleDeleteRow.
• Failure conditions: no selection; synchronous nested cell-change callbacks; changeCellValue() or deleteRecords() throwing; mixed existing/new-row deletion.
• Regression coverage: useOperationRecord.test.tsx.
• Rollback path: revert this PR; there are no migrations or feature flags.

Contributor declaration

• I linked the Issue that defines this change.
• I tested the affected behavior and reported the actual results above.
• I did not include credentials, private data, or generated build output.
• I disclosed substantial AI assistance below, or this PR contains no substantial AI-generated code.

AI assistance: OpenAI Codex performed code-path analysis, authored the focused fixes and regression tests, reviewed exception and nested-callback paths, and ran the reported checks under maintainer direction.