Changes

Under experimental.advancedRouting, the composable astro/hono pages() handler delegated straight to PagesHandler.handle(), with none of the app-level error handling that AstroHandler provides on the standard path. A page throwing during render therefore propagated to the host framework, which answered with its own default error response (Hono: plain-text Internal Server Error) instead of rendering the custom 500.astro page (#16952).

• Added PagesHandler.handleWithErrorFallback(app, state) (core/pages/handler.ts): wraps route dispatch in a try/catch that logs the error and renders it via app.renderError(..., { status: 500, error }), the same behaviour AstroHandler.render() has on the standard path. Forwarding error keeps the documented error prop on 500.astro working. The logic lives in the handler module because core/fetch/index.ts deliberately keeps its exports as thin, logic-free wrappers.
• When no route matched, handleWithErrorFallback() returns a 404 response marked with X-Astro-Error (the same pattern handle() uses for the un-dispatched redirect case), so the app's existing post-check renders the 404 error page a level up. This case is reachable because Fix 404 route resolution for experimental.advancedRouting with astro/hono handlers #16911 intentionally leaves routeData unset when the custom 404 route is prerendered (or absent), where PagesHandler.handle() would otherwise throw a TypeError and the catch would turn those unmatched requests into 500s. The 500 path keeps calling renderError() directly: the marker cannot carry the error object, so 500.astro would lose its error prop and the stack would not be logged.
• Switched pages() in core/fetch/index.ts to delegate to the new method (delegation only, no logic added).
• Added a changeset (astro patch).

Testing

• Added 'renders the custom 500 page when a page throws during render' - verifies the full pages() pipeline returns HTTP 500 with the custom 500 page content when a page throws during render
• Added 'returns a marked 404 for the app post-check when the custom 404 route is prerendered' - verifies unmatched requests return HTTP 404 carrying the X-Astro-Error marker instead of throwing
• Verified end-to-end against the reproduction from Custom 500.astro not rendered for render-time errors under experimental.advancedRouting + astro/hono pages() #16952 (Hono + app.use(pages()), node standalone): GET /boom -> 500 with the custom 500 page (previously Hono's plain-text Internal Server Error), GET /does-not-exist -> 404 serving the prerendered 404 page with the marker stripped from the final response, GET / -> 200; the thrown error is logged with its stack trace

Out of scope (noticed while testing)

Errors thrown by Astro middleware itself (src/middleware.ts) on the composable path (app.use(middleware())) still reach the host framework's default error handler instead of 500.astro. On the standard path, AstroHandler.render()'s try/catch wraps the whole middleware chain, so middleware errors get the same 500.astro treatment. The equivalent catch can't simply live inside the composable middleware(): its next is the host's next(), so it would also intercept errors thrown by host middleware running below it in the chain and hide them from the user's own app.onError. The all-in-one astro() handler already provides full parity. A possible follow-up would be an error-page helper exported from astro/hono (e.g. app.onError(onError())) so composable users can opt in - happy to open a separate issue for this.

Docs

• No docs update needed, this fixes broken functionality in an experimental feature so it matches the documented custom-error-page behavior (the 404 counterpart was Fix 404 route resolution for experimental.advancedRouting with astro/hono handlers #16911)

Closes #16952