feat(meta,core,app,android,ios): cast and trailer

AniList's fragment now asks for the first ten characters, main roles
first, with their Japanese voice actor, and for the trailer's site and
id. Both are stored in the existing details JSON as TitleDetails.cast and
.trailer with serde defaults, so no migration is needed and details
stored before them still read. The details REVISION goes to 2, so a
stored match is refetched by its id on the next metadata run and the
cast fills in without anyone matching the title again.

The title page shows a Cast row of round portraits with the character's
name over the actor's. Clicking a tile opens the Person browse page for
that actor, which now also admits voice actors, and search counts them
under People and studios. A Trailer button opens the YouTube or
Dailymotion page in the browser; the app itself makes no request to
either, and an unknown site or an id with odd characters gives no link.

docs/METADATA.md

@@ -162,6 +162,17 @@ match. The same scoring, seeded by the title most recently watched to the end
 and limited to titles not started, is the library's *Because you watched* row.
 No request: it reads only what the match already stored.
 
+**Cast and trailer.** The AniList query also asks for the first ten
+characters by role, main ones first, each with their Japanese voice actor and
+both portraits, and for the trailer's site and id. They are
+`TitleDetails::cast` and `TitleDetails::trailer`, in the same JSON column — no
+migration. `TitleDetails::REVISION` is 2, so a match stored before them is
+fetched again by id on the next match run, as `runtime` was. A voice actor's
+chip opens the same page as a director's (`Facet::Person`). The trailer is
+only ever a link: `Trailer::url` builds the YouTube or Dailymotion address,
+keeping only an id's own characters, and the browser opens it. Portraits are
+fetched like posters, from AniList's image host.
+
 **Android.** The same, through the bridge: `AndroidEngine::arrangement`
 returns the grid's tiles and the shelves as keys into `library`'s titles, and
 each `TitleRecord` carries its display name, franchise and details. The

docs/PRIVACY.md

@@ -18,6 +18,9 @@ Nothing else leaves your device. There is no telemetry, no crash reporting and n
 of the titles in your library. It does not learn your files, your watch history or your shares.
 Turning them off deletes every stored answer.
 
+**Trailer** on a title's page opens the trailer's YouTube or Dailymotion page in your web
+browser. The app sends nothing there itself; your browser loads the page as it would any link.
+
 ## Secrets
 
 - **The part of a share link after `#`** is the key that decrypts the share. The app treats it as

docs/USER_GUIDE.md

@@ -114,6 +114,12 @@ top.
   franchise, and shows one title from each other franchise. It needs posters and descriptions.
 - The genre chips under the description open a page with every title of that genre in your
   library. So do the **Studio** and **Director** chips. Back, or **Esc**, returns to the title.
+- **Cast** lists the main characters and who voices them in Japanese. Click one to see every title
+  in your library with that voice actor. Search finds voice actors too.
+- **Trailer** opens the title's trailer in your web browser. The app does not play it or load it
+  itself.
+- Titles matched before this version get their cast and trailer by themselves the next time the
+  app looks up posters and descriptions.
 - With posters and descriptions on, a show's logo takes the place of its name at the top of the
   page and on the library's banner, and each episode says how long it runs. A film says how long
   it runs in the line under its name.