Fix stale application status updates in UI

[shivanshmishra54]

Fixes #4599\n\nApplication snapshots received through the SSE stream were applied without checking their status timestamp. An older snapshot could therefore overwrite a newer status and make a healthy application appear DOWN in the UI.\n\nThis change ignores an incoming snapshot when its application status timestamp is older than the currently displayed snapshot. A regression test covers a newer DOWN snapshot followed by an older UP snapshot.\n\nValidation:\n- npm run test -- --run src/main/frontend/store.spec.ts\n- npm run lint (pre-existing warnings only)\n- npm run build

[cdprete]

Events are already returned in a sorted fashion by the backend (see https://github.com/codecentric/spring-boot-admin/blob/master/spring-boot-admin-server/src/main/java/de/codecentric/boot/admin/server/eventstore/ConcurrentMapEventStore.java#L79) so, unless I'm missing something, I can't see how this should help.

[SteKoe]

Hi @shivanshmishra54, thanks for taking the time to look into this and for adding a regression test. I'm going to close this PR, for these reasons:

1. The ordering guarantee belongs on the server.
We prefer not to add client-side guards against out-of-order events. The server should send events in the correct order, and a guard in the UI would hide server-side bugs instead of fixing them. If snapshots can be reordered, that is a bug in ApplicationRegistry.getApplicationStream(). It uses flatMap for the per-event lookups, and flatMap doesn't preserve ordering. The right fix is there, for example with concatMap.

2. The guard would cause regressions.
Application.statusTimestamp is an aggregate computed in ApplicationRegistry.getStatus. It isn't a monotonic per-snapshot version.

• When the last instance is removed, the server returns Instant.EPOCH. The guard would drop that update, so the application would never be removed from the UI.
• Deregistering one instance can legitimately move the aggregate timestamp backwards. The guard would discard that update and keep showing stale state.

3. It doesn't fix #4599.
As @cdprete found in the issue, the journal is missing STATUS_CHANGED events, and StatusUpdateTrigger appears to stop for some instances. In that case the backend never emits the newer snapshot, so there is nothing for the client to compare against. Because of that, please don't link this PR as fixing #4599. I'm leaving the issue open.

Where a contribution would help

• Investigating why StatusUpdateTrigger stops, or why status changes aren't journaled (see Bug: Instance reported as down even if it's up #4599 and Help needed: Random TimeoutException #4516).
• Making getApplicationStream() order-preserving, with a test in ApplicationRegistryTest.
• A separate issue: store.ts subscribes to the SSE stream only after GET /applications completes (concat(list, stream)), so events emitted in between can be lost.

You're welcome to open a new PR for any of these. Thanks again!