feat(trailers): let a user choose where trailers come from

[IbbyLabs]

Summary

Lets a user point trailers at any Stremio addon that returns a YouTube id, instead of taking whatever the metadata provider supplies.

default     the metadata provider's own trailers, as today
streailer   shows a link to Streailer's configure page
custom      paste any trailer addon's manifest URL

streailer and custom are the same code path; the preset only points at where to get the URL. It deliberately does not prefill one: an unconfigured Streailer URL returns that addon's own default language, so filling it in would hand the user a working-looking setting they never chose.

If you would rather not name a third-party service in the settings page, delete the streailer entry from trailerProviders. The custom option carries the feature without it.

Linked issue

Closes #669

Type of change

• Bug fix
• New feature
• Refactor
• Tests only
• Documentation only
• CI / tooling

Why this approach

A Stremio addon's manifest URL already carries that addon's own configuration, so its language setting travels with the URL the user pastes. Nothing here builds a config, which matters: Streailer answers a wrongly-shaped config path with 200 and its default language, so a URL assembled by this addon could ignore the setting without ever failing.

Taking a URL rather than a named provider list means the next trailer addon needs no code change. The stream endpoint is derived from the manifest URL by string swap, and a URL not ending in /manifest.json is refused rather than guessed at.

Applied once in getMeta rather than per builder, since trailer source is a user preference rather than a property of whichever provider answered. A failed or empty lookup leaves the provider's own trailers in place.

The same boundary fills trailerStreams for every provider when a builder left it empty. Stremio's meta object carries trailers in two fields and nothing here filled that one; Cinemeta emits both. getCache.ts carries the field in the trailers component so it survives a rebuild from cache.

This changes what existing users see. Anyone with another metadata addon installed has been getting that addon's trailers for titles this one also has; they will now get these. That is the intent, but it is a behaviour change rather than a new setting they opted into.

Modelled on the existing posterRatingProvider for the type declaration, the context default and the search-index entry, and on the movie and series selects in the same file for the SettingRow + ProviderSelect pair.

Testing

An addon returns 200 with an empty streams array for a title it does not know, not a 404. That was checked against a live instance, and it is why the guard is on the number of usable ids rather than on res.ok — keying on the status alone would replace good trailers with an empty list on every unknown title.

case	result
manifest URL carrying a language	derives the matching stream URL, verified against a live instance
plain manifest URL	derives stream/<type>/<id>.json
URL not ending in /manifest.json	refused
empty or missing URL	refused
unknown title	provider's own trailers left in place

tsc --noEmit is clean across the repo.

Tested on a live instance running this branch: selecting a trailer addon and
pasting its manifest URL returns that addon's trailers, and leaving the setting on
default leaves the metadata provider's own trailers untouched.

A multi-arch preview image of this exact commit:

docker pull ghcr.io/ibbylabs/aiometadata:pr672-2ee7da53

• I ran existing tests relevant to this change.
• I added or updated tests where needed.
• No tests were needed, and I explained why.

The repository has no test suite or test script, so there was nothing to run or extend. What was exercised is described above.

Documentation

• I updated documentation or comments where needed.
• No documentation updates were needed.

The setting is self-describing in the configure UI, and the addon URL field says where to configure the addon's own language.

Author checklist

• This PR is focused on one concern.
• This PR is reasonably small and reviewable.
• I read and followed CONTRIBUTING.md.
• I can explain every code change in this PR.
• I will respond to review feedback myself.

AI usage disclosure

• No AI tools were used.
• AI tools were used for part of this PR, and I personally reviewed and verified all changes.

[github-actions]

PR Guard

• All automated intake checks passed.

Maintainers may still close PRs that do not match project direction or review capacity.