Customer chat: switching tickets can leave the thread scrolled to the previous ticket

[marassteiner]

Follow-up from #1297 (not a merge blocker). Uncertainty noted: this is a real path for customers with more than one ticket, but it is recoverable by scrolling and does not lose messages.

Evidence

src/screens/chat.screen.tsx:134 — the scroll effect keys only on supportIssue?.messages.length. hasScrolledToEndRef and prevMessageCountRef are not reset when the issue UID changes.

src/App.tsx:328-333 mounts ChatScreen on both /support/chat and /support/chat/:id. The parent SupportChatContextProvider stays mounted. On /support/chat/:id the screen writes the new UID and replaces to /support/chat without calling loadSupportIssue. The remounted screen then:

1. briefly renders the previous issue still sitting in context,
2. marks hasScrolledToEndRef true against that old length,
3. then loadSupportIssue clears the issue (node_modules/@dfx.swiss/react sets supportIssue to undefined and isLoading true) and loads the new one.

If the new ticket has the same number of messages or fewer, added <= 0 and the customer is left at the top of the new thread. isNearBottom can remain true from the previous scroll, so the jump button may also stay hidden.

Tests always use one issue UID.

Suggested fix

Reset scroll/unread refs when supportIssue.uid or sessionUid changes, and do not render a context issue whose UID does not match the requested session.