Fix large Telegram SQLCipher imports at SQLite's locking page

A user reported a deterministic HMAC failure at page 262145 in a 24.3 GB native Telegram database, while a smaller account imported successfully. With 4096-byte pages, this is SQLite's reserved locking page at the 1 GiB boundary, not an ordinary unauthenticated data page.

Checks both the page's exact reserved position and that the entire page is zero before preserving it. Every data page and non-zero locking page still requires a valid HMAC. Adds all-page-size regressions, an opt-in built-CLI integration proof, documentation, and changelog credit.

• Removes a deterministic import blocker for large native Postbox databases containing SQLite's reserved zero locking page.
• Avoids a blanket integrity bypass: neighboring zero pages and non-zero unauthenticated locking-page content remain rejected.
• Exercises the complete CLI path through account validation, decryption, extraction, archive writes, and message reads beyond the reserved page.

• Regressions cover all eight supported page sizes from 512 to 65,536 bytes, including rejection of neighboring zero pages and non-zero unauthenticated content.
• The PR documents a before/after built-CLI run on a generated 1,096,318,976-byte SQLite fixture: the baseline failed at page 262145; the candidate imported and read a message from root page 267656.
• The PR reports full local make check validation; GitHub test, lint, dependency, Docker, release, and secret checks passed. The verified merge commit credits Goutam Adwant, and the merged changelog explicitly thanks him for the fix.
• Proof used generated data, not the reporter's private database. Whole-database decryption and SQLite deserialization still require substantial RAM; this change does not implement streaming imports or establish success on the reported 24.3 GB database.