URL mapping returns 404 at runtime when detail page uses custom Page content type (follow-up to #35149)

[DeanGonzalez]

Problem Statement

Issue #35149 fixed the save-time validation in DetailPageTransformerImpl.validateIdentifier() so that custom Page content types (e.g., "Landing Page") are no longer rejected when saving a Content Type's detail page configuration.
However, a runtime 404 is still occurring when dotCMS attempts to resolve a URL-mapped request to a detail page that uses a custom Page content type.

Observed Behavior

Content Type JaMuseumDecade has URL pattern /museum_decade/{urlTitle}
Detail page is set to //global/detail-pages/museum-decade-detail-page (a custom "Landing Page" content type, not htmlpageasset)
The detail page inode was set via DB workaround (page_detail column in structure table), as the UI fix was applied after the workaround was needed
The detail page exists, is published/Live, and is accessible on global.ja.org
Requesting https://siteb.com/museum_decade/1920 returns a 404 Not Found
The same URL pattern and detail page setup works correctly for pages using the standard htmlpageasset content type

Root Cause Hypothesis
The save-time fix in #35149 corrected DetailPageTransformerImpl, but the runtime URL mapping resolution path may contain a separate or related check that still fails for custom Page content types. Specifically, when dotCMS resolves an incoming URL against a content type's URL pattern and attempts to locate and render the mapped detail page, it may be performing a similar htmlpageasset subtype check that causes the resolution to fail silently and return a 404.
The original issue description noted:

"Pages set as detail pages before this validation was introduced still work at runtime (URL mapping reads directly from the DB)"

This suggests the runtime path reads page_detail from the DB correctly, but may fail at a later step when attempting to render the resolved page if it is not of type htmlpageasset.

Steps to Reproduce

1. Create a Content Type with base type Page using a custom name (e.g., "Landing Page" with velocity variable landingPage)
2. Create and publish a page using that custom Page content type and add the detail page on a global host (e.g., //global/detail-pages/my-detail-page)
3. Create a Content Type with a URL pattern (e.g., /museum/{urlTitle}) and set the detail page to the page from step 2 (now possible via UI after Custom Page content types rejected as detail pages due to hardcoded "htmlpageasset" subtype check #35149 fix, or via DB workaround)
4. Create and publish a content item of that Content Type on a completely different host
5. Request the front-end URL matching the URL pattern (e.g., https://demo.dotcms.com/museum/my-item)
6. Observe: 404 Not Found is returned instead of the rendered detail page

Acceptance Criteria

The request should resolve correctly, using the custom Page content type detail page as the rendering template, and return a 200 with the rendered content — consistent with how htmlpageasset detail pages behave.
Environment

Replicate behavior experienced on the client site:

• Detail page: //global/detail-pages/museum-decade-detail-page
• Test URL: https://siteb.com/museum_decade/1920
• dotCMS Version: Current (post 26.04.02-01)

dotCMS Version

26.03.27-01

Severity

High - Major functionality broken

Links

High — customers who configure custom Page content type detail pages (now permitted by the #35149 fix) will be unable to use URL mapping at runtime. The UI fix is effectively unusable without a corresponding runtime fix.
Links

Parent issue: #35149
Freshdesk ticket: https://helpdesk.dotcms.com/a/tickets/36039

[github-actions]

PRs linked to this issue

• fix: url map 404 on different host (#35268) by @gortiz-dotcms