fix(replay): trust SDK-supplied session_id in handleReplay (follow-up to #318)

[ayushjhanwar-png]

Why this is needed

PR #318 made the SDK pass its localStorage / Firebase-UID-based deviceId to `/track/device-id?deviceId=`, and the server returns the matching session_id from the `sessions` table. The SDK then includes that session_id with every replay chunk.

But the replay handler (`handleReplay`) was still overriding `payload.session_id` by recomputing deviceId from IP + UA and looking up a session for that hash — re-introducing the NAT-collision behavior on the replay storage path:

```
SDK sends: session_id = "real-session-from-sessions-table"
Server overrides: session_id = lookup-by-IP+UA hash (could be a different session)
CH stores: session_replay_chunks.session_id = the-overridden-id
↑ doesn't match sessions.id → "Session not found"
```

Verified on dev: track flow correctly created a session under the SDK's localStorage UUID, but replay chunks landed under a session keyed by the IP+UA hash. Two separate sessions, same human.

The fix

Trust the SDK-supplied session_id when present. Fall back to the IP+UA derivation only when the SDK didn't send one (older SDKs that pre-date the deviceId override path).

```diff

• let sessionId = payload.session_id;
• if (ip && ua) {

• let sessionId = payload.session_id;
• if (!sessionId && ip && ua) {
  ```

Why this is safe now (unlike #315 which was reverted)

PR #315 had the SDK generate its own session_id (a random UUID with no row in `sessions`). Trusting it broke the dashboard's session lookup ("Session not found"). #317 reverted that.

This time the SDK's session_id is not self-generated — it comes from `/track/device-id`, which is a real row in `sessions` for the same deviceId the track flow used. So:

```
sessions.id ← server-issued, real row
sessionId on the wire ← echoed back to SDK, same value
chunks.session_id ← now also that value
```

All three match. Dashboard finds the session. Replay plays.

Backward compatibility

• Modern SDKs (1.3.0+): `payload.session_id` is the server-issued id → trusted as-is. ✅
• Legacy SDKs (1.1.x): `payload.session_id` may be empty/stale → falls through to the existing IP+UA derivation (unchanged behavior). ✅

Test plan

• Typecheck — 18 pre-existing errors, no new
• Deploy to dev, verify on local frameo:
  • Anonymous user: localStorage UUID gets a session in `sessions`; `session_replay_chunks.session_id` matches `sessions.id` ✅
  • Office colleague: gets their own UUID → different session → different replay timeline ✅
  • Dashboard "session details" page finds the session and plays the replay ✅