[27/33] The trash, seen: a screen for it, and the settings that govern it

[cerede2000]

Batch 27 of the plan in #373: the trash, seen. Branched from main and touching none of the files #410–#415 touch, so it can be merged in any order with them.

The trash arrived with its engine in #405: deleting moves an item into the volume's reserved space, it is restorable, it is swept on a schedule, and an administrator can set a retention. None of that is visible. There is no way to see what was deleted, no way to put it back, and the settings can only be written through the API — the feature exists and nobody can use it.

What it does

• A screen that lists what you deleted, newest first, with where it came from, who deleted it, when, when it will be removed for good, and what it costs. A deleted folder opens, so one file can be taken back out of it without restoring the whole thing.
• Restore, delete for good, empty. Emptying asks first. Restoring puts an item back where it came from, taking the next free name rather than replacing whatever has taken its own since ([18/33] Never let a file operation replace or merge into what holds a name #404).
• An unreachable item is shown as unreachable, with the reason, rather than hidden: a volume that is not mounted any more should not make a trash look empty.
• Share links follow. Links suspended with the item are restored or dropped, which the dialog asks about when there are any.
• Settings for an administrator, at Settings → Trash and versions: whether deleting goes to the trash, the retention, the share of the volume it may take and a size cap — and the same for the versions kept in the same space. The server has answered both sections since they landed; the settings store now carries them.

Notes for review

• Two things are deliberately left to the batches that bring what they need: reading the text of a file while it is still in the trash (it wants the text service, batch 26), and restoring into a chosen folder rather than where the item came from (it wants the destination dialog, which comes with the file operations). Neither is referenced anywhere in this batch.
• features now answers whether the trash is on to the client as well — the server already said so, nothing read it, so the way in could not be shown or hidden.
• One helper was added to utils (formatLocalDateTime), used by both screens.
• The fifteen catalogues carry the strings; nothing here is untranslated.

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 backend suite is unchanged — the same two failures main gives on its own in a full run, nothing new;
• the image was built and driven in a browser: a file deleted through the API appears in the trash with its original location and its removal date, the sidebar offers the way in, restoring from the screen puts the file back in its folder and says so, and Settings → Trash and versions renders both sections with the values in force. Screenshots in the pull request thread.