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/progress.md

@@ -467,8 +467,13 @@ Electron cases with substituted model output; live-provider checks remain opt-in
   migration and backup requirements are defined in the
   [storage contract](./technical-design.md#file-storage-and-writes).
 - The startup worker converts one entry per transaction and verifies hydrated
-  readback before clearing the legacy payload. Reclamation checks the freelist
-  on every attempt, including retries after conversion has finished. Committed
+  readback before clearing the legacy payload. The original implementation checked
+  the freelist on every attempt. This was narrowed by the September 21 startup
+  fix and the September 26 structure-upgrade fix: only a required legacy
+  conversion enables reclamation, with its decision retained for same-startup
+  retries, not later launches. Current rules are in the
+  [migration contract](./technical-design.md#schema-38-migration).
+  Committed
   saves/deletes/resets remain successful when manifest or GC cleanup fails;
   failures are logged and cleanup is retried on later access or reopen.
 - Storage implementation handoff reports 135/135 focused tests passed across

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