UVE language switch on detail pages checks/translates the page, not the urlContentMap content

Problem Statement

On a URL-content-map (detail) page in the Universal Visual Editor (UVE), switching the viewing language operates on the page, not on the content the detail page is rendering. This is a pre-existing defect in the shipped language-switch flow — it was discovered while investigating spike #36348, but it is not introduced by that spike.

A detail page is a single page asset reused across many content items via a URL map. The meaningful question when switching language is "does this content item have a version in the target language?" — but UVE only ever asks "does the page have a version in the target language?"

Concretely, two things are wrong on detail pages:

1. Detection checks the wrong asset. The "missing translation" decision is driven entirely by pageTranslateProps → the page-scoped languages list from getLanguagesUsedPage(page.identifier) (GET /api/v1/page/{id}/languages). It never inspects the urlContentMap contentlet's languages. As a result a detail page can be reported as "translated" while the content shown is not (and vice-versa).
2. The translation action targets the wrong asset. When the user accepts the "Create new language version?" prompt, the legacy flow builds an edit-contentlet URL with _content_sibbling = pageInode — i.e. it creates a new version of the page, not of the urlContentMap content the user is actually looking at.

A content-scoped check already exists and is the correct signal to use: DotLanguagesService.get(contentInode) → GET /api/v2/languages?contentInode={inode} → backend LanguageAPI.getAvailableContentLanguages(contentInode, user), which returns the languages the content exists in. The urlContentMap object carries inode, identifier, and contentType (it extends DotCMSBasicContentlet), so the data needed to do this correctly is already on the page asset.

Impact: Editors working with detail/content-driven pages get confusing or incorrect multilingual behavior — prompted to translate the "page" when they need to translate the content, or not prompted at all when the content is missing in that language. Front-end (UVE), all browsers.

Steps to Reproduce

Detailed steps:

1. Have a content type with a URL map (detail page) and at least one content item that exists only in the default language (e.g. English).
2. Open the detail page for that item in UVE (so urlContentMap is populated).
3. Switch the language selector to a second language (e.g. Spanish).
4. Observe that the "missing translation" decision and the resulting "create new language version" action are based on the page, not on the content item being rendered:
   • The prompt/decision reflects the page's languages, not whether the content item is translated.
   • Accepting the prompt creates a new version of the page, not a translation of the urlContentMap content.

(Video screencast to be attached once reproduced in a running environment.)

Acceptance Criteria

• On a URL-content-map (detail) page, the "missing translation" check is based on the urlContentMap content's languages (via getAvailableContentLanguages / GET /api/v2/languages?contentInode=), not the page's languages.
• On a detail page, the translation action creates/targets a language version of the urlContentMap content (its identifier + contentType), not the page.
• Normal (non-detail) pages keep the existing page-scoped behavior.
• The store exposes a content-aware "is translated" signal for detail pages so the toolbar/effect can branch correctly (the current pageTranslateProps answers the page question only).

dotCMS Version

Latest from main branch (pre-existing; present in the current shipped UVE language-switch flow).

Severity

Medium - Some functionality impacted

Links

• Discovered during spike: dotCMS/core#36348
• Related original issue: dotCMS/core#35647
• NA (no Freshdesk ticket)

Start with the UVE language-switch flow, including pageTranslateProps, the toolbar/effect, and DotLanguagesService.get(contentInode). Trace how urlContentMap provides inode, identifier, and contentType, then verify the content-scoped language check and translation target while preserving page-scoped behavior for normal pages. Done means the store exposes the detail-page signal and the acceptance criteria pass for both detail and non-detail pages.