fix: improve screen events reliability - flush on close, handle 2xx/4xx, add event_uid

[shameondev]

Summary

• Fix 2a: Handle non-JSON 2xx responses gracefully (try-catch around deserialization for success codes)
• Fix 2b: Only rebuffer events on 5xx server errors, not 4xx client errors (prevents infinite retry on permanent failures)
• Fix 1: Flush remaining events on screen close (onScreenClosed() now calls flush() after tracking screen_closed)
• Fix 3: Generate UUID v4 event_uid per event in track() for deduplication

Context

Part of Screen Events Reliability initiative (5 repos). Ships with next SDK release (Phase B).

Files changed

• NetworkClientImpl.kt — wrap deserialize in try-catch for 2xx
• ScreenEventsServiceImpl.kt — 4xx no-rebuffer, event_uid generation
• ScreenPresenter.kt — flush on screen close

Test plan

• TC-1.1: Events flushed on screen close (short session < 10 events)
• TC-1.3: Flush after batch already sent (12+ events then close)
• TC-2.2: No retry loop on 202
• TC-2.5: 4xx errors not rebuffered
• TC-2.6: 5xx errors still rebuffered
• TC-3.2: event_uid present in POST body (UUID v4 format)

[SpertsyanKM]

I'm afraid this can break the current logic anyhow. I'm not sure that falling back to an empty map in several cases is a good idea.