fix(urlmap): use configured detail page when not found on requesting site (#35268)

[dsilvam]

Proposed Changes

• In URLMapAPIImpl.getDetailPageUri(), when the configured detail page lives on a different host (e.g. //global/) and no matching path exists on the requesting site, fall back to the configured identifier instead of returning Optional.empty().

Root Cause

The runtime URL map flow has two steps:

1. buildContentQuery() — finds the URL-mapped contentlet via ES, restricted to +(conhost:<currentSite> OR conhost:SYSTEM_HOST) ✅
2. getDetailPageUri() — resolves the rendering page from the content type's detailPage identifier

Step 2 correctly handles the case where the detail page is on the current host. When it isn't, it tries to find a page at the same path on the current host. If nothing is found (e.g. the page is on //global/), it was returning Optional.empty() → 404. The fix returns the configured identifier directly as a safe fallback.

Content host isolation is fully preserved — only step 1 determines which contentlet is returned, and that query is never modified.

This restores the targeted getDetailPageUri() fallback that was reverted in #35622 alongside the unsafe cross-site ES query change. The unsafe buildContentQuery() change is not reintroduced.

Checklist

• Tests — processURLMap_detailPageOnDifferentHost_shouldResolveWithConfiguredDetailPage added to URLMapAPIImplTest; existing cross-site bleed guard processURLMap_mustNotReturnContentFromForeignHost_whenRequestingHostHasNoMatch still passes
• Translations
• Security Implications Contemplated — detail page is admin-configured (not user-supplied); content query host restriction unchanged

Additional Info

• Regression of Custom Page content types rejected as detail pages due to hardcoded "htmlpageasset" subtype check #35149 / follow-up to URL mapping returns 404 at runtime when detail page uses custom Page content type (follow-up to #35149) #35268
• Previous fix attempt (fix: url map 404 on different host (#35268) #35345) introduced multi-tenant content bleed (bug(url-map): cross-site content bleed in multi-brand setups — unrestricted fallback query returns wrong tenant's content #35616) and was reverted (revert(urlmap): revert PR #35345  #35622). This fix addresses only the getDetailPageUri() path, not buildContentQuery().
• All 20 URLMapAPIImplTest tests pass (1 pre-existing @Ignore skipped)

Closes #35268

This PR fixes: #35268

[claude]

Claude finished @dsilvam's task in 2m 26s —— View job

---

dotCMS Backend Review Pipeline

• Load dotCMS conventions (CLAUDE.md, Java standards, security principles)
• Get Java diff
• Run specialized sub-agent reviews (Security, Database, Java Standards, REST API)
• Consolidate findings
• Post backend review comment
• Submit formal GitHub review (auto-approve blocked by GitHub permissions — manual approval required)

---

All four specialized reviewers (Security, Database, Java Standards, REST API) returned no findings.

The change is a targeted one-liner in URLMapAPIImpl.getDetailPageUri(): instead of returning Optional.empty() when no matching page exists at the same path on the requesting site, it now falls back to return Optional.of(identifier) (the admin-configured detail page). Content host isolation is not affected — buildContentQuery() still restricts the ES query to conhost:<currentSite> OR conhost:SYSTEM_HOST. The new integration test correctly validates both the happy path (detail page on a different host resolves) and the existing cross-site bleed guard.

Note: I'm unable to submit a formal GitHub review approval due to GitHub App permissions. You can find more information and potential workarounds in the FAQ.

[claude]

✅ dotCMS Backend Review: no issues found.