feat(ja.mangarawjp): add sort filter for updated and ranking orderings

[kinboy56]

Summary

Adds a sort filter to ja.mangarawjp. The browse tab previously had no way to reach anything by order — it was hardwired to the site's empty-search endpoint, which returns the catalogue in the site's own default order, so finding something popular or recently updated meant already knowing its name.

• New res/filters.json with a sort filter: 最近の更新 and ランキング, defaulting to the former
• get_search_manga_list maps the selected option to its own path
• config.hidesFiltersWhileSearching set, since the search endpoint cannot take an ordering
• Listing scraping extracted into parse_listing_page, shared by search and browse
• Source version bumped 1 → 2

Implementation notes

The site has no sort parameter — each order is served from a separate path:

Sort option	Endpoint
最近の更新 (default)	/page/N/
ランキング	/ranking/N/
search	?s=<query>&page=N

A few things worth a reviewer's attention:

• A query wins over the sort value. Searching is a separate endpoint that no ordering can be applied to, so hidesFiltersWhileSearching hides the filter, and a non-empty query takes precedence over whatever sort value is still stored. An empty query is not treated as a search and falls through to the ordering paths. test_query_takes_precedence_over_sort guards the first case and test_empty_query_falls_through_to_the_sort the second.
• Page 1 of the updates ordering is the site home page, and that page stacks four sibling div.post-list blocks with no distinguishing class: updates, ranking, and one per featured genre (Ecchi / オトナ). Selecting .post-list > a there returns 84 entries from all four blocks with 7 duplicates, instead of the 24 that actually belong to page 1. Entries are therefore scoped to the first .post-list only. Every other page — /page/2/ onwards, /ranking/N/, and the search endpoint — has exactly one such block, so the narrower selector is correct everywhere, not just on the home page. test_updated_page_1_holds_only_the_updates_block asserts both no-duplicate-keys and a page-size bound so this can't regress silently. The home page is unavoidable here: the "もっと" link on the updates block points at /page/2/, so there is no dedicated URL serving page 1 of that ordering.
• A missing .post-list is an error, not an empty page. An exhausted listing still renders the block with nothing inside it (/page/9999/ returns 200 with an empty block), so the two cases are distinguishable: no block at all means the page didn't load. Returning an empty list there would be indistinguishable from the end of pagination, and in the app it leaves the previous list on screen — which reads as the ordering having been ignored.
• Hrefs are read as-is rather than with abs:. Manga.key is the site-relative path (/manga-raw/...), which is exactly what the href already holds, so reading it directly avoids resolving to an absolute URL only to strip the base back off. Covers do need absolute URLs and are joined onto BASE_URL, reading data-src only — the plain src is a base64 placeholder until the page's lazy loader runs, so falling back to it would yield a data URI.
• /page/1/ is used rather than / even though they serve identical content, to keep one URL shape per ordering instead of special-casing the first page. Same for /ranking/1/, which the site redirects to from /ranking/1.

Test plan

• cargo test --release — 12 tests against the live site, all passing: both orderings return entries, they return different leading keys (so the filter is provably not a no-op), a query beats a stored sort value while an empty query does not, updates page 2 paginates, keys stay site-relative and covers absolute, out-of-range pages end pagination cleanly, the sort index falls back to the first option when the app sends no filter value, and the home-page block-mixing regression guard
• Regression guard verified by reverting the selector to .post-list > a and confirming test_updated_page_1_holds_only_the_updates_block fails (84 entries, 77 unique), then restoring
• test_query_takes_precedence_over_sort verified by disabling the query branch and confirming it fails, then restoring — asserting on titles alone would not have caught the fallback, since the query is also the top ranking entry
• cargo fmt --check — clean
• cargo clippy --release — no warnings
• aidoku package + aidoku verify — source.json, filters.json and the icon (128×128, fully opaque) pass schema validation
• Verified on device (iOS): the sort filter shows both options in the filter sheet with 最近の更新 selected by default, switching to ランキング swaps the list, and the filter is hidden while a search is active

Checklist

• The source can be compiled without any warnings or errors
• cargo fmt has been run before submission
• cargo clippy outputs no lint warnings
• All files have an additional newline at the end
• JSON files use tabs for indentation
• Manga.key / Chapter.key unchanged — no migration needed, so no breakingChangeVersion
• Source version incremented
• Home components — not implemented (optional per CONTRIBUTING.md)

[kkantan]

I think, rather than listings, it would be better to have a sort filter that is hidden while searching. it's nicer to have a single page for the source instead of separating the search and listings, and since filters are saved locally, people can set a default sort.