fix: preserve UI error details and publish debug images

[shahargl]

When the root layout fails, the global error page calls session-dependent API hooks after Next.js has removed their providers. The fallback then crashes too, masking the original error. Render a provider-independent fallback with the original error reference and retry action.

Add a release workflow for versioned ghcr.io/keephq/keep-frontend:<version>-dev images using the production server with browser source maps and console output retained. Pass KEEP_INCLUDE_SOURCES into the Docker builder, correct the Sentry sourcemaps option, and allow source-map requests only for builds that explicitly include sources. Document how to use the images behind an existing proxy or in Kubernetes.

Preserve the existing session initialization: seeding the session earlier caused the alert table to stall during hydration in the E2E run. Give the Test alerts button an accessible name and a stable test ID. Update the theme E2E test to use explicit controls, wait for submission to finish, and wait for the expected row colors after applying each theme.

Closes #6546
Closes #6549

Validation

• 41 targeted tests pass across the global fallback, source-map configuration, OAuth2-proxy identity parsing, sign-out, API authentication handling, and the Test alerts button.
• Local production compilation completed successfully. Three browser runs against a mock API with 6× CPU throttling loaded alerts and applied both Keep and Basic themes; all three runs stalled before removing the session initialization change.
• Updated Python E2E test passes syntax validation.
• Full TypeScript check still reports 10 errors in existing, unchanged test files; no new diagnostics.
• Release workflow YAML and version/tag extraction checked; generated provider snippets validated.
• Docker build checks report seven existing Dockerfile warnings. Debug images have not been published.
• The reporter's Keycloak/oauth2-proxy deployment has not been reproduced end to end. The fallback now preserves any original error that was previously masked by the secondary crash.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.41%. Comparing base (620adaf) to head (a5a6e26).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #6852       +/-   ##
===========================================
+ Coverage   30.45%   46.41%   +15.95%     
===========================================
  Files         101      178       +77     
  Lines       11785    18715     +6930     
===========================================
+ Hits         3589     8686     +5097     
- Misses       8196    10029     +1833     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[senpro-ingwersenk]

Thanks a lot for this PR!

Here is what I gathered after switching from v0.54.3 to current main:

Something went wrong
C.map is not a function

Try again

Console:

installHook.js:1 TypeError: C.map is not a function
    at w (AlertsLinks.tsx:153:27)
    at l9 (react-dom-client.production.js:4354:1)
    at o_ (react-dom-client.production.js:6453:1)
    at oq (react-dom-client.production.js:7429:1)
    at ik (react-dom-client.production.js:11182:1)
    at react-dom-client.production.js:11059:35
    at ib (react-dom-client.production.js:11060:1)
    at iu (react-dom-client.production.js:10630:1)
    at iG (react-dom-client.production.js:11963:1)
    at iW (react-dom-client.production.js:11833:1)

This is the particular snippet failing:

            options={tags.map((tag) => ({
              value: tag.name,
              label: tag.name,
            }))}

Interestingly, tags should have that method:

// AlertLinks.tsx @ L 38
const { data: tags = [] } = useTags();

So, I went hunting:

Interestingly, as I was setting up breakpoints and watchers, eventually it just...started working. o.O The error did not return again. That said, I did notice that something was up with my Websocket connection.

Going to fix that first and then see what happens after. For now, this is where I am; it randomly decided to work again...for now, let's see how long it stays.

[senpro-ingwersenk]

Soketi is fixed now.

   [Mon Sep 28 2026 09:20:00 GMT+0000 (Coordinated Universal Time)] 👨‍🔬 New connection:
{ ws: uWS.WebSocket { ip: '10.42.2.56', ip2: '', appKey: 'keephq' } }
   [Mon Sep 28 2026 09:20:00 GMT+0000 (Coordinated Universal Time)] ✈ Sent message to client:
{
  ws: uWS.WebSocket {
    ip: '10.42.2.56',
    ip2: '',
    appKey: 'keephq',
    sendJson: [Function (anonymous)],
    id: '6130195587.6349546895',
    subscribedChannels: Set(0) {},
    presence: Map(0) {},
    app: App {
      initialApp: [Object],
      server: [Server],
      enableUserAuthentication: false,
      hasClientEventWebhooks: false,
      hasChannelOccupiedWebhooks: false,
      hasChannelVacatedWebhooks: false,
      hasMemberAddedWebhooks: false,
      hasMemberRemovedWebhooks: false,
      hasCacheMissedWebhooks: false,
      id: 'keephq',
      key: 'keephq',
      secret: 'keephq',
      maxConnections: -1,
      enableClientMessages: false,
      enabled: true,
      maxClientEventsPerSecond: -1,
      maxPresenceMembersPerChannel: 100,
      maxPresenceMemberSizeInKb: 2,
      maxChannelNameLength: 200,
      maxEventChannelsAtOnce: 100,
      maxEventNameLength: 200,
      maxEventPayloadInKb: 100,
      maxEventBatchSize: 10
    },
    timeout: Timeout {
      _idleTimeout: 120000,
      _idlePrev: [TimersList],
      _idleNext: [TimersList],
      _idleStart: 42001,
      _onTimeout: [Function (anonymous)],
      _timerArgs: undefined,
      _repeat: null,
      _destroyed: false,
      [Symbol(refed)]: true,
      [Symbol(kHasPrimitive)]: false,
      [Symbol(asyncId)]: 120,
      [Symbol(triggerId)]: 0
    }
  },
  data: {
    event: 'pusher:connection_established',
    data: '{"socket_id":"6130195587.6349546895","activity_timeout":30}'
  }
}

And, now, the error also seems to be gone?

I will keep an eye on this, it'd be quite hilarious if the misconfigured soketi was the issue all along...

[senpro-ingwersenk]

So far, after fixing up any outstanding error regarding soketi (like, for example, fixing typos socketi -> soketi...) I have not yet encountered the error again.

The error usually would come back a day later when my session has, in theory, "expired". So we'll see what happens in days to come. Will keep the updates here. :)

(I can only use Slack at home for several reasons, by the way.)