docs(changelog): correct the v1.38.5 backup claim

The entry said the weekly pass finishes again. It was written from a
measurement taken on a development machine with a multi-gigabyte heap,
and it does not hold on a small container: capped at 1 GB the runtime
gets a 524 MB heap, and the pass still runs out of memory there. It gets
roughly three times further than before, which is a real improvement and
is now described as one, but it does not complete, and the failure takes
the whole process down rather than failing as a job.

Building the record incrementally instead of whole is the fix and has not
landed. Until it does, an instance backing up a large record needs more
than 1 GB, and the entry says so.

CHANGELOG.md

@@ -2,8 +2,9 @@
 
 ## [1.38.5] — 2026-09-03
 
-The weekly backup finishes again, the dashboard stops scanning the two
-largest tables, and several settings now do what they say.
+The weekly backup costs a fraction of the memory it did, the dashboard
+stops scanning the two largest tables, and several settings now do what
+they say.
 
 ### Security
 
@@ -27,10 +28,20 @@ largest tables, and several settings now do what they say.
   which is four full copies of the record at the same moment. The stored copy
   is now compressed before it is encrypted, which takes an order of magnitude
   off everything after it, and the pass releases each stage before allocating
-  the next. A seeded 445 000-reading account went from dying of memory to
-  finishing in about twenty seconds, with a stored copy of 25 MB instead of
-  322 MB. The pass also has an explicit two-hour window now, so a genuinely
-  slow disk cannot be mistaken for a broken run. The nightly off-host copy is
+  the next. A seeded 445 000-reading account, on a machine with
+  a generous heap, went from dying of memory to finishing in about twenty
+  seconds, with a stored copy of 25 MB instead of 322 MB. The pass also has an
+  explicit two-hour window now, so a genuinely slow disk cannot be mistaken for
+  a broken run.
+
+  **That measurement does not carry to a small container, and this entry
+  originally over-claimed from it.** A container capped at 1 GB gives the
+  runtime a 524 MB heap, and against one of those the pass still runs out of
+  memory, roughly three times further along than before but short of the end.
+  Worse, it takes the whole process down with it, so a failed backup becomes an
+  outage for everyone else on the instance. Building the record incrementally
+  rather than whole is the actual fix and has not landed yet. Until it does, an
+  instance backing up a large record wants more than 1 GB. The nightly off-host copy is
   built the same way and got the same treatment; files written before this
   still restore, and so do backups already sitting in the database.
 - **A failed backup run is now visible on the backups page.** The weekly pass