feat: add ja.soraraw

[kinboy56]

Summary

• Search, browsing/filtering, series details, chapter lists, and page lists
• Three listing types: Latest, Popular, Trending
• Search by title, alternative title and author
• Dynamic genre filtering, fetched from the site rather than hardcoded
• Deep linking capabilities for series and chapter URLs

Implementation Notes

• Search walks the catalogue dump the site publishes, because nothing else on it can be
  queried. /search?q= is statically generated and ignores the query — the browser downloads a
  catalogue and filters it itself. The api host does expose /search, but it answers 500 for every
  query (Unknown column 'Manga.number_views' in 'ORDER BY'), and /mangas ignores every query
  parameter it was tried with. The dump is 13 pages of 2000 entries, about 4.7 MB over the wire
  with the gzip the host serves.
• Search cannot be combined with the other filters, so config.hidesFiltersWhileSearching is
  set.
• The reader is picked from genres, not from the mode field. mode describes how the site's
  own reader lays a series out, not what kind of comic it is: across 31 series measured, every
  horizontal one held page-shaped art, but so did a third of the vertical ones — ordinary
  japanese manga that would otherwise open in a continuous scroll. The overseas genres track the
  content instead, appearing on 2 of 7021 horizontal series and 644 of 979 vertical ones across
  8000 catalogue entries, which matches the share of vertical series that really are webtoons.
• Image proportions are deliberately not used to pick the reader. Korean webtoons on this site
  are cut into page-shaped chunks about as often as into tall strips, so the shape of a page says
  nothing about whether the panels are meant to run together.
• Page file extensions are probed with one HEAD request per chapter. Of 50 chapters sampled
  across the catalogue, 47 held webp and 3 held jpg, with nothing in the page list telling the two
  apart.
• Page names are rebuilt from the fields that aren't encrypted. Every entry in the page list
  also carries the name of the file on each image server, encrypted with a key the site's scripts
  derive at runtime; the order and id fields are handed out in the clear and are enough.
• Content ratings follow the site's own adult flag. Deriving anything further from genres was
  tried and dropped: genre names are not unique (41 of the 1834 the site lists are used by more
  than one genre), and the ones that read as suggestive are already flagged as adult by the site
  itself, so a name-based guess disagreed with the site more often than it added anything.
• Publishing status may be absent from a response, which maps to MangaStatus::Unknown rather
  than falling back to ongoing.
• Chapter language is intentionally omitted to prevent filtering issues on a single-language
  source.

Known limitation: chapters served as one stacked image

A small share of chapters are served as a single image holding every page of the chapter stacked on
top of each other. Those are handed over whole, so the reader shows them as one very tall page.

Measured on "BLUE GIANT MOMENTUM":

Normal chapters	24 images of 1448x2048
Chapters 66 to 70	one image of 1450x49152 — 24 pages of 2048px stacked

5 of that series' 71 chapters are affected, and other series are too — "となりの黒川さん" serves
chapter 49 as one 800x24003 image holding 21 pages. Nothing in the response separates the two
cases: every chapter carries mode: "image", and a stacked chapter lists exactly one page named
001_{id} like any short chapter would, so only the shape of the image itself gives it away.

Splitting them was implemented and works up to the point of display. The page count comes out right
and the cuts land exactly on the page boundaries — scanning the difference between neighbouring
pixel rows around every expected cut put all 23 boundaries of the blue giant image at an offset of
0 (row difference 88.5 at the cuts against 15.5 inside a page), and all 20 of the kurokawa image
likewise. On device, however, every slice rendered blank while the page count stayed correct. Both
ways of handing the slices over behaved identically:

• returning them as PageContent::Image from get_page_list
• returning the same url with a PageContext per slice and cutting in PageImageProcessor

Since neither renders, the splitting is left out of this PR rather than shipped broken, and the
affected chapters remain readable as a single tall page. I am leaving the decision on how to proceed with this limitation to the reviewer.

Test Plan

18 tests cover the functionality against the live site:

• All three listing types and their pagination
• Search by title, by alternative title and by author
• Genre filter parsing and the dynamic filter list
• Series metadata, including the reader picked for webtoons, for ordinary manga the site marks as
  vertical, and the adult flag
• Page lists, chapters stored as jpg, non-integer chapter numbers, and a malformed chapter key
• The payload decoding, checked without touching the network
• Deep link parsing with edge cases
• Regression coverage for the stacked chapter above, so it stays readable rather than failing

Code quality checks passed: cargo test, cargo fmt, cargo clippy, and aidoku verify.