sqlite3_backup copies a native DoltLite image, not a SQLite page file

Replaces #1839, which claimed `sqlite3_backup_init` rejects, `sqlite3_serialize` returns NULL, and memdb never opens. That is no longer true.

`sqlite3_backup_step()` copies a file-backed, attached, or in-memory DoltLite database as **one operation** (the page-count argument is not incremental). `sqlite3_serialize` / `sqlite3_deserialize` use a contiguous **native DoltLite** image (commit graph, refs, working sets), not a SQLite page image. Documented in README SQLite Compatibility (`c_api.backup`, `c_api.serialize`).

Inherited `backup2` / `backup4` assertions still fail because they compare SQLite file hashes, pager page counts, and in-memory pager backup. Those remain `unsupported`: the APIs work, they just do not produce a stock SQLite file.

This issue is the live description those gates should cite. It is not a request to emit SQLite page images.

Start with the README SQLite Compatibility section, especially c_api.backup and c_api.serialize. Then inspect the inherited backup2 and backup4 assertions that compare SQLite file hashes, pager page counts, or in-memory pager backup. Done means the documentation and those gates clearly identify native DoltLite images and unsupported stock-SQLite-file assumptions.

Written by the indexing model from the issue text.