Describe the bug
On an Emby media server, every movie rule action (Radarr) fails with Couldn't resolve any supported external IDs for movie with media server ID <id>, even though the Emby item clearly has TMDB and IMDb IDs. The rule matching works (the collection fills with the expected movies), but the action can never resolve a TMDB id, so nothing can be unmonitored/deleted/etc.

Root cause appears to be in apps/server/src/modules/metadata/metadata.service.ts → getHierarchyResolutionItem():

const hierarchyTargetId = item.grandparentId ?? item.parentId;
if (!hierarchyTargetId) return item;
const hierarchyItem = await mediaServer.getMetadata(hierarchyTargetId);
return hierarchyItem;   // IDs are resolved from the PARENT, not the item

This is correct for episodes (resolve from the series), but for an Emby movie parentId points at an ID-less container, so the movie's own provider IDs are discarded → 0 lookup candidates → RadarrActionHandler.handleAction hits the lookupCandidates.length === 0 branch and aborts. It fails silently (no MetadataService debug/warn) even with LOG_LEVEL=debug.

To Reproduce
Steps to reproduce the behavior:

1. Connect an Emby server as the media server.
2. Create a movie rule that builds a collection (Radarr action; mine is "Unmonitor", but any servarr action reproduces it).
3. Open the collection, pick a movie, and click "Trigger Rule Action".
4. See the error in the logs: Couldn't resolve any supported external IDs ... Failed to trigger the collection action for this item.

Expected behavior
Maintainerr should resolve the movie's TMDB id (which is present on the Emby item) and perform the Radarr action against the matching movie.

Screenshots
Emby's "External Ids" panel for the affected movie shows valid IMDb (tt0109040) and TheMovieDb (3049) IDs, so the data exists on the item. (Screenshot can be attached.)

Device (please complete the following information):

• OS: Unraid 7.1.4 (official image ghcr.io/maintainerr/maintainerr:latest, deployed via Docker Compose). Note: not host-specific — this is deterministic application logic and reproduces independent of host.
• Version: 3.14.0
• Server: Emby 4.10.0.14

Debug logs

LOG_LEVEL=debug was active (verified). Relevant excerpt from a fresh boot + one reproduced trigger (full scrubbed log attached). Note that the failure path emits nothing beyond the two lines below — no MetadataService debug/warn — which is consistent with resolution returning empty before validation runs:

[maintainerr] | 08/06/2026 15:36:44  [INFO] [EmbyAdapterService] Emby connection established to <MEDIA_SERVER> (v4.10.0.14)
...
[maintainerr] | 08/06/2026 15:43:01  [INFO] [RadarrActionHandler] Couldn't resolve any supported external IDs for movie with media server ID 301282. Please check this movie manually.
[maintainerr] | 08/06/2026 15:43:01  [ERROR] [LogsController] Failed to trigger the collection action for this item.
TriggerRuleActionButton.handleTriggerAction

Additional context

Evidence (live GET /api/media-server/meta output):

The movie itself has the IDs:

// GET /api/media-server/meta/301282  (Ace Ventura: Pet Detective)
{ "id":"301282", "type":"movie", "parentId":"75481",
  "providerIds": { "imdb":["tt0109040"], "tmdb":["3049"], "tvdb":[] } }

Its parent (what resolution actually reads) is an ID-less "movie" container:

// GET /api/media-server/meta/75481
{ "id":"75481", "type":"movie", "childCount":1, "parentId":"44982",
  "title":"Ace Ventura Pet Detective (1994)",
  "providerIds": { "imdb":[], "tmdb":[], "tvdb":[] } }

So the real IDs live on 301282, but resolution reads 75481 (empty). Additionally, all collection_media rows are stored with tmdbId = NULL, so the fallback { tmdb: media.tmdbId } in RadarrActionHandler can't rescue the lookup either.

Ruled out:

• TMDB key — reproduced with both the built-in shared key and a personal key; GET /3/movie/3049 returns 200 from the container's network.
• Connectivity — TMDB, Emby, and Radarr are all reachable from the container.
• Emby metadata — Emby returns correct providerIds for the movie.
• Host (Unraid/Docker) — deterministic application logic; no host-specific factor in this code path.

Suggested fix: Only use hierarchy resolution for episodes/seasons (resolve up to the show), not for movies — or prefer the item's own provider IDs when present before walking up. For Emby/Jellyfin, movies should resolve from the movie item itself.

Related issues (not duplicates): the phrase "supported external IDs" returns no existing issue.

• Certain media not being deleted with 3.4.1, correctly deleting in 3.3.0 #2638 (Plex, fixed v3.5.0) — a year/title validation rejection; here validation never runs (silent, reads the ID-less parent).
• TmdbApiService - Failed to resolve external IDs #2990 (Plex, fixed via fix(plex): don't drop auth when plex.tv is unreachable #2996) — different error/code path (TmdbApiService batch), already in 3.14.0.
• Maintainerr incorrectly overrides correct TVDB ID via TMDB cross-reference #3010 (Jellyfin, fixed fix(metadata): keep media-server ids unless corroborated; accept on provider year agreement (#3010) #3011) — TVDB-correction logic, unrelated to the Radarr movie action.

maintainerr-bugreport-scrubbed.log