Cartographer: fix OOM when backing up servers with many attachments

[RWolfyo]

The problem

FileBackup.serialize downloads each attachment, base64-encodes it, and holds it on the model until the entire guild has been serialized. Peak memory therefore scales with a server's total media — about 4x it, since the raw bytes, the base64 bytes and the decoded str are all live at once, before model_dump_json builds the document on top.

The v2.2.0 check is per-file:

files=[await FileBackup.serialize(i) for i in message.attachments if i.size < max_size]

That rejects individual oversized files but places no ceiling on the total, so any number of small attachments passes straight through.

On my bot this produced a 1.9 GB backup document and a ~16 GB RSS peak against a 16 GB MemoryMax, and the OOM killer ended the process roughly every 10 minutes — last_backup never persisted, so every restart retried the same backup and died again. Restoring such a backup would have failed the same way, since restorelatest does model_validate_json(path.read_text()) on the whole file.

The change

Backups are written as .zip — backup.json plus an attachments/ folder. Attachments stream into the archive as they download; on restore they are read back one at a time. Memory stays flat regardless of media volume, and nothing is dropped: a large backup simply takes longer.

A backup is still a single file on disk, so the rotation, wipe, listing and size-reporting paths are untouched.

Backward compatible. load_backup picks the format by extension and FileBackup keeps filebytes for pre-2.3.0 backups. Existing backups load and restore unchanged; only new ones are zips.

The guild upload limit check is unchanged — same filesize_limit fallback, same comparison.

Second commit

Unrelated bug found while testing: channel.history(limit=...) returns newest-first and restore_channel_messages replays the list in order, so restored channels came back backwards. Messages are now stored oldest-first; the same most-recent N are still selected. Kept as a separate commit so it can be dropped independently.

Testing

Run against a live bot (Red 3.5, Python 3.11):

• Backup + restore of a server with 52 MB of mixed attachments (images, mp4): 288 MB → 444 MB RSS, plateauing rather than climbing. All attachments restored intact.
• Legacy .json backup restored successfully via the base64 fallback.
• Message ordering verified chronological after the second commit.
• Archive round-trip checked against unicode filenames, duplicate filenames, path-traversal-style names, and empty files.

Version

2.2.0 → 2.3.0 — minor rather than patch, since the on-disk backup format changes.