[26.2/33] A file's history, seen: the panel, the administrator's list, and one reader for text

[cerede2000]

The second half of batch 26. #415 made a file's history real and readable through the API; nothing showed it. This is the panel, the administrator's list, and reading text wherever it lives.

What this adds

A history you can see. A file with earlier versions carries a small mark in the listing, with how many. Clicking it opens the panel: what was kept, who saved it, where it came from, and — per version — read, download, restore, name, pin, delete. Restoring keeps what it replaced, so going back loses nothing. The mark is counted once per folder rather than once per row, and a user preference turns it off, which takes the query away as well as the icon.

An administrator's view. Every file that has a history, wherever it is, with what it takes up; a history can be emptied from there. Those routes name a history by its own id rather than by a path: the ones worth finding include files that no longer exist, and a history whose file was deleted outside the application has no path to ask about and no file to authorise against. They sit behind ensureAdmin for the same reason.

One reader for text. The editor, a version and a file still in the trash now read through the same service — the last two are what #415 and #416 left out.

Defects fixed on the way

All four live in the editor's own read and save path, which this batch owns.

• A UTF-16 file was refused as binary. Every letter of English in UTF-16 is accompanied by a zero byte, and a zero byte was the test for binary. That is what Out-File wrote by default until PowerShell 6 and what Notepad still offers as "Unicode": an export or a log from a Windows machine could not be opened at all. A mark is believed when there is one; otherwise the pairing of zeros decides, which is what tools writing UTF-16 without a mark leave behind.
• A save wrote UTF-8 over whatever the file was. It reads perfectly well here and breaks whatever wrote it. A save now keeps the file's encoding.
• The size limit was checked when opening and not when saving. A paste larger than the limit was written, and the file could then never be opened again. Checked now on the bytes about to be written — in UTF-16, twice the characters.
• The editor opens 2 MiB and saves through a JSON body whose limit was Express's default of 100 kB. A file between the two opened and could never be saved, answered "request entity too large", which names neither limit. They are one decision now: the body limit is derived from what the editor may open, and a limit somebody set is a ceiling that is never raised from here — the editor is what gives way.

And one found while wiring the panel up: marksForFolder, listFilesWithVersions, readFileVersions and deleteFileVersions all called store helpers that were never added. Nothing called those four, so nothing noticed; all of them threw. The queries are here, and each has a test.

Also: the editor's read is now a GET the browser keeps and revalidates, answered 304 while the file is unchanged — so opening the editor from the Markdown preview stops downloading the same file twice. The identity includes the inode, because a save writes a new file and renames it over the old one.

Left for later, deliberately

• Taking a version out as a new file, and putting a version over another file: both need the destination dialog, which is not here.
• Reading a version of an office document in its editor: needs the office editors to accept one — batch 28.
• The activity-log entry for a purge: waits for the log.

Gates

• Lint and formatting on the changed files.
• npm run build; every backend module loads.
• The whole backend suite: 1,949 pass, against the two that fail on main before any of this (auth.test.js, browse-hidden-files.test.js — measured on main itself, not assumed).
• 40 new tests. Every claim above fails when the change behind it is put back; UTF-16 detection was mutated twice, once for the mark and once for the pairing, because they are two mechanisms.
• The image is the gate for the screens. Built, started, driven in a browser: two saves, the mark reading 2, the panel opening from the mark, a version read in the read-only viewer, a version restored from the panel with the history growing to three, a file deleted and then read from the trash by double-clicking it, and the administrator's list showing the file with its space. That is how the last defect here turned up — the dialog confirming a restore teleports to the body and stacked below the panel's overlay, so its buttons could not be clicked. No unit test would have seen it.

Independent of the stack; applies on current main.