Fix Cursor composer headers SQL-table migration

[Interittus13]

Newer Cursor builds migrate composer.composerHeaders out of ItemTable into the dedicated composerHeaders SQL table. Load, scan, rewrite, and persist headers from that table when the legacy blob is absent so rebind no longer fails with composer.composerHeaders not found.

Summary

This PR adds compatibility with Cursor's newer composer-header storage format while preserving support for the legacy ItemTable format.

• Detect and load headers from the composerHeaders SQL table when composer.composerHeaders is absent.
• Propagate the detected storage source through discovery and rewrite flows.
• Persist rewritten headers back to the SQL table during exact-mode rebind.
• Avoid recreating the legacy composer.composerHeaders ItemTable entry when Cursor is using the SQL-table format.
• Add coverage for legacy, SQL-table-only, and missing-header cases.

Test plan

• go test ./...
• Manual smoke (scan / map; migrate only on a disposable Cursor storage copy if writes changed)
• Verified exact migrate against a real Cursor SQL-table-backed storage copy and confirmed chats were successfully moved.

Notes

• The SQL-table format has been observed in newer Cursor builds, including Cursor 3.19+.
• The existing legacy composer.composerHeaders ItemTable path remains unchanged.
• Prefix-mode SQL persistence remains limited compared with exact-mode persistence; this PR primarily targets the exact path/workspace rebind flow.
• No legacy composer.composerHeaders blob is recreated when the source database uses the dedicated SQL table.