fix: avoid history reclamation during structure-only upgrades

Ordinary database schema upgrades previously ran VACUUM on free pages and
showed misleading history-cleanup progress. Separate structure upgrades from
required legacy conversions, retaining reclamation intent only for retries
within the same startup. Preserve released data without new schema versions
or persistent migration markers; Agent and normal writes remain unchanged.

Add real SQLite and Worker regressions, bilingual operation-specific startup
copy, and migration documentation. Synchronize native Electron drag input
with actual resize state without weakening layout assertions.

Validation: 47 focused migration tests passed; typecheck, lint and diff checks
passed. Final full suite: 5137 passed, 74 skipped, 2 unrelated Electron failures.
Both failing Electron tests passed an isolated rerun; full CI remains unverified.

Release note: 修复普通数据库结构升级再次整理历史和回收空间的问题；仅在需要转换旧数据时执行相关处理，启动页准确显示当前升级操作。

docs/features/magic-notes/technical-design.md

@@ -175,12 +175,16 @@ Already converted entries are reconciled on retry. Matching body revisions do
 not require rehydrating binary payloads. Direct `AssistantDatabase.initialize`
 callers and tests also run storage repair.
 
-Space reclamation is separate from conversion. Every worker attempt checks
-`PRAGMA freelist_count` and runs checkpoint/VACUUM when free pages remain.
-Cancellation after the last converted entry or a VACUUM failure therefore
-allows reclamation to retry on the next startup, even with no legacy rows left.
-The schema marker alone does not establish that conversion and reclamation
-finished. General migration requirements are in the
+Space reclamation is separate from structure upgrades and conversion. Startup
+detects legacy note payloads and retains the conversion/reclamation decision in
+memory for that startup's worker retries. Only a required legacy conversion
+permits checking `PRAGMA freelist_count` and running VACUUM. A structure-only
+upgrade does not repair notes in the worker or reclaim ordinary free pages.
+Cancellation after conversion or a VACUUM failure can retry reclamation within
+the same startup. After quitting, startup checks the schema and remaining legacy
+payloads again; free pages alone do not trigger another upgrade, and SQLite can
+reuse them. No additional persistent migration marker is stored.
+General migration requirements are in the
 [database migration guide](../../development/database-migrations.md).
 
 ## Backup and Restore