[26/33] A text save keeps what it replaced, and a history can be read

[cerede2000]

Batch 26 of the plan in #373, first half: what a text save leaves behind, and reading a history. Branched from main and touching none of the files #410–#414 touch, so it can be merged before or after them, in any order.

The versions engine landed with #406 and the office editors started feeding it in #410. Two things were still missing, and they are the same subject: the text editor wrote straight over the file, and nothing could read a history back.

What it does

• A text save keeps what it replaced. PUT /api/editor wrote the file directly, so a stop halfway through left it truncated and the state it replaced was gone. It goes through versions.saveFile now: written beside the file, put in place once whole, and the previous content kept. Somebody pressed Save, so the state is marked as deliberate — there is no editing session here to group it with, as there is in the office editors.
• A save carrying something that is not text is a bad request, rather than a server error raised after the document has already been opened for writing.
• A history can be read. GET /api/versions?path=… answers a file's versions with who saved each one and where it came from; /versions/:id/content hands one over; /restore puts one back and keeps what it replaced, so going back loses nothing; /copy writes one beside the file under a name of its own; /replace writes it into another file; PATCH /versions/:id labels or pins; /versions/delete removes some or all.
• A version is only ever reached through the file it belongs to, with that file's rights: asked for under another path, it does not exist.

Notes for review

• No schema change: the tables arrived with [20/33] File versions: keep what a save replaces, and let history follow the file (engine) #406. No new dependency, no frontend change — the panel that shows this is the second half of the batch.
• Three things are deliberately left to the batches that bring what they need: reading a version as text (it wants the text service), the purge entry in the activity log, and telling an open ONLYOFFICE document that the file was restored under a new key.
• folderSizeHooks and the recent-destinations service that this code calls in our fork are not here, and nothing else in this tree notifies folder sizes from a write path, so both were dropped rather than invented.

How it was checked

On main at 7b07337, Node 24 as the CI and the image use:

• the frontend bundles and every backend module loads (the CI's own two steps), migrations included;
• the backend suite gives the same four failures a full run gives on main untouched, which I measured on main itself rather than trusting a note: auth.test.js "current password is incorrect" and browse-hidden-files.test.js fail every time, and users.test.js (lockout) and userSearchService.test.js (limit) are load-sensitive — they pass when run alone, before and after this change. Nothing new fails, and the count of tests goes up by seven;
• seven new tests drive the editor and the history from outside — save, save again, read what was kept, restore it, ask for a version under the wrong file — and four of them fail when the save is put back the way it was.