MID-9998 Fix stale page recovery after view-source

[kay1313]

Summary

Fixed MID-9998: internal server error after viewing page source and returning to midPoint.

The issue was caused by StalePageException being handled by LoggingRequestCycleListener as an unexpected rendering error and converted to PageError, which produced a user-facing HTTP 500.

StalePageException is a Wicket stale page/render-count recovery case, for example after browser view-source, back/forward navigation, duplicate tabs, or similar stale page requests. It should be recovered by re-rendering the stale page instead of being converted to the generic error page.

Changes

• Added special handling for StalePageException in LoggingRequestCycleListener.
• Re-render the stale page using RenderPageRequestHandler with RedirectPolicy.ALWAYS_REDIRECT.
• Keep the stale page recovery log at debug level instead of treating it as an unexpected error.
• Added LoggingRequestCycleListenerTest to verify that StalePageException is recovered with RenderPageRequestHandler and is not converted to PageError.
• Added release notes entry for MID-9998.

Testing

• Added unit test:

  • LoggingRequestCycleListenerTest.testStalePageExceptionIsRecoveredInsteadOfConvertedToPageError

• Manually verified original reproduction scenario:

  1. Open midPoint locally.
  2. Go to Users → All users.
  3. Press Ctrl+U to display page source.
  4. Return to the midPoint UI.
  5. Click logo/Home or another navigation target.

Expected result: no HTTP 500 is shown. The stale page is recovered/re-rendered. A second click may be needed to perform the original navigation after recovery.