v0.76.0: Hide a chapter that does not belong

Hide a chapter a source lists that is not part of the series, and the extension engine gets the memory it really
uses. Hiding is @Squeaks72's idea, from pull request #240,
rebuilt to hide only: nothing is ever deleted. The engine's memory was reported by @Kedryn
(#275). Thank you both.

Hide a chapter that does not belong

• A source sometimes lists a chapter that is not part of the work, such as a 0.5 from an unrelated title or a number a
  wrong match brought in. Nothing on the source's side takes it away. An admin can now hide that number with
  Hide chapter N in a chapter's or a grey row's ⋯, or Hide n chapters in the select bar. It asks first.
• A hidden chapter is gone for everyone: the chapter list and its grey rows, the reader's next and previous, Continue,
  the unread counts and badges, Updates, history, Insights, OPDS and the Komga-compatible API. Neither Health nor the
  reader's note about missing chapters counts it as missing, and Health does not call it an impossible number.
• It is never downloaded, by the nightly check, Check for new chapters, Fetch newest, the slow archive or Find missing
  chapters. A download already waiting when you hide it stops before it asks the source.
• Nothing is deleted. The file, the chapter's row and everyone's reading progress stay as they were, and neither the
  read-chapter cleanup nor Fix everything touches it.
• More → Show hidden chapters lists what is hidden and what each one is, with Restore and Restore all. A
  restored chapter is back everywhere at once, and the next check fetches it if it is missing.
• Merging two series keeps what either one hid, and renumbering a series by posting order moves a hidden number with
  its post.

The extension engine gets the memory it uses

• Its memory ceiling is 2 GB, up from 1.5 GB (#275, reported by
  @Kedryn). Its Java heap stays at 768 MB. The rest of the ceiling is for what the heap does not cover: Java's own
  native memory, and the Chromium and Xvfb the engine runs, which came to 770 MB beside a 630 MB heap on a server with
  45 extensions. At 1.5 GB that server's engine lived only by swapping; on a server without swap, Unraid's default, the
  kernel kills it at the ceiling instead, which is what #275 reports.
• MALLOC_ARENA_MAX=2 on the engine's container. The C library otherwise keeps what a thread frees in that thread's
  own arena, up to eight arenas per CPU core: 94 of them held 428 MB on that server, and two held about 120 MB less
  under the same load.
• The engine's card on Admin → Sources says it uses 1 to 1.5 GB, where it said about 750 MB. That figure is the
  desktop app's engine, which runs without Chromium.

Upgrading

• ⚠️ An existing install keeps its old engine settings. An update changes the image, never your compose file, your
  Unraid container or your CasaOS app.
  If the engine keeps restarting has the two settings to add, and
  how to tell whether the ceiling is what stops it.
• Database: additive only. A nullable hidden_numbers column on lib_series and a small partial index, created
  when the server starts. The previous release starts on this schema and shows every chapter.
• API: new POST /api/admin/series/:id/chapters/hide, POST /api/admin/series/:id/chapters/unhide and
  GET /api/admin/series/:id/chapters/hidden. POST /api/sources/fetch skips a hidden number as hidden, and the
  series DTO carries hiddenChapters for an admin.

Uchiyomi Desktop (beta): downloads

Uchiyomi as a program on your own computer, for Windows and Mac. On first launch it asks how you want to
use it: on this computer (the whole app, with the library in a folder on your PC and no Docker or
server to run) or connected to your own Uchiyomi server (a window onto the server you already run).

Your computer	Download
Windows (x64)	Uchiyomi-Setup-0.76.0.exe
Mac with Apple silicon (M1 or newer)	Uchiyomi-0.76.0-arm64.dmg
Mac with an Intel processor	Uchiyomi-0.76.0-x64.dmg

Only those three are for you: the .zip, .blockmap and latest*.yml files are what the app's own updater
reads. The same installers are also here under names without a version (Uchiyomi-Setup.exe,
Uchiyomi-mac-arm64.dmg, Uchiyomi-mac-x64.dmg), which always lead to the newest release.

The app is not signed yet, so the first launch takes one extra step:

• Windows: "Windows protected your PC" appears once. Choose More info, then Run anyway. A PC
  with Smart App Control turned on blocks unsigned apps with no way past it; use the Docker install there.
• macOS: open the dmg and drag Uchiyomi to Applications. The first time you open it, macOS refuses;
  go to System Settings → Privacy & Security and choose Open Anyway.

Windows installs updates by itself. A Mac cannot update an unsigned app, so there a new version is a new
download; the menu-bar icon and Admin → Health say when one is out.

Step by step, with pictures -- which file, the first launch on each system, the two ways to use it, adding
sources, updates, backups, where files live and uninstalling:
the desktop guide.