fix(ja.soraraw): tolerate null genre rows

[kinboy56]

Summary

Fetching details for a series whose genre list holds an empty row fails the whole request, so the
series cannot be opened at all.

Genre declared name and slug as String. A few series carry genre rows the site never filled
in — every field but the id is null — and serde rejects the row, which fails the deserialization
of the entire page payload. The series then returns an error instead of details or chapters.

This widens both fields to Option<String>:

• Genre::into_tag drops a row with no name, alongside the existing check that drops an empty one
• MangaDetails::viewer picks the reader from the slugs that are present, using filter_map
  instead of map

Nothing else changes. A series with ordinary genre rows behaves exactly as before.

The rows in question

majime-fumajime-maji-koiji-64273 is the example the test uses. Its genres array:

[
  { "id": 12,   "name": "日常",       "slug": "nichijou" },
  { "id": 17,   "name": "コメディ",   "slug": "komedi" },
  { "id": 24,   "name": "ロマンス",   "slug": "romansu" },
  { "id": 2211, "name": null,         "slug": null },
  { "id": 2212, "name": null,         "slug": null }
]

Ids 2211 and 2212 are absent from genres.json, which lists 1909 genres, none of them null. So
these look like rows the site deleted from the genre table while leaving the join rows behind — the
manga page joins against the missing ids and gets nulls back. That makes it a data-shape the source
has to tolerate rather than something the site is likely to clean up.

Testing

19 tests pass, including a new test_null_genres, which fetches the series above and asserts the
details request succeeds and still returns the three real genres as tags. It fails against the
previous revision with unexpected page data.

cargo fmt, cargo clippy --release, cargo test --release, aidoku package and
aidoku verify package.aix are all clean.

Not device tested — the fix is in deserialization and the test runner exercises the same path.

version — needs a decision

Set to 2 here, but #697 also raises it from 1 to 2 for the same source. Whichever merges second
needs 3 instead. I have left both at 2 rather than guess at the merge order; tell me which one you
would like to take first and I will rebase the other and set the number.

The two changes do not otherwise overlap: this one touches models.rs, #697 touches helpers.rs
and lib.rs, and the only shared file is res/source.json on that one line.

This is the smaller and more clearly scoped of the two, and it fixes series that currently do not
open at all, so it may be worth taking first regardless of where #697 lands.

[kkantan]

the other pr should increment the version to 3, since it is an additional change and cannot come before aidoku is updated.

I would like to suggest not using an llm to generate pr descriptions. this is a very simple fix that shouldn't require more than one or two lines of explanation. I know english is not your first language, so using an llm for translation or assistance is acceptable, but larger descriptions can cause more important information to be obscured.