Read a PDF where it is imported, and keep the text with the file

A PDF was searchable on a device once that device had opened it, because
the extracted text lived in that browser's IndexedDB and nowhere else. So
a document imported on the desktop was invisible to a search on the
phone — which is exactly the case that matters for filing invoices, since
those are imported and then never opened again.

The reading still never happens on the server. It has no PDF library and
is not getting one: the bytes arrive encrypted and are stored that way.
The device that imports the file reads it there and then, and the result
is stored beside the file in attachments.text_index, encrypted at rest
like everything else and opaque to the server. Every other device asks
for it after login and can then find a document it has never downloaded.

Not storing it was the earlier decision, on the reasoning that text
derivable from bytes the server already holds should not be kept twice.
True, and useless. A few hundred kilobytes against a file measured in
megabytes is a trade worth making.

A `null` answer is not an error — it means nobody has read this file yet.
Documents extracted before this existed are sent up the next time they
are opened.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -8,6 +8,33 @@ not from the output of `docker push`.
 
 ---
 
+## Unreleased
+
+**Added**
+- **A PDF is searchable on every device, not only on the one that opened it.**
+  The device that imports the file reads it there and then — the server still has
+  no PDF library and never opens one — and the extracted text is stored beside
+  the file, encrypted, so every other device can find the document without ever
+  downloading it. This is what makes an archive of scanned invoices work: they
+  are filed and then never opened, so waiting for someone to open one meant
+  waiting forever.
+- **A drawing runs over as many pages as the note has.** The ink used to be stuck
+  on page one while the writing carried on without it. Pages are numbered the way
+  the PDF reader numbers them, and there is always one blank page past the end to
+  start a new one on. The bin clears the page being looked at; undo still works on
+  the drawing as a whole.
+- A drawing that lives entirely on page one is still stored in the old shape, so
+  an ordinary note is written exactly as it always was and an older client still
+  shows it.
+
+**Fixed**
+- **A drawing exported in a ZIP was lost on re-import.** The exporter has written
+  `drawings/<note>.png` since the interface was put into English; the importer
+  was still looking for `zeichnungen/<note>.png` and found nothing. Both names
+  are read now, and so are the further pages of a drawing.
+
+---
+
 ## 2026-08-11 — The writing column
 
 **Images** — web `sha256:ed11f034…`, server unchanged at `sha256:1648498f…`