perf(chat): cap mobile memory with content-visibility on messages (#2391)

* perf(chat): cap mobile memory with content-visibility on messages

Long conversations render every message at once (no virtualization). On
mobile WebKit each tab renderer has a hard ~2 GB cap; a few hundred laid-out
messages plus paint backing stores exceeds it, so iOS Safari jetsam-kills the
tab and shows "A problem repeatedly occurred".

Add content-visibility:auto + contain-intrinsic-size to each message wrapper so
off-screen messages skip layout and paint, keeping peak renderer memory bounded.
content-visibility implies paint containment, so overflow-clip-margin is added to
keep the copy/retry/edit controls (which sit just below each message) painting.

* fix(chat): converge scroll-to-bottom for content-visibility messages

content-visibility:auto messages start at their contain-intrinsic-size estimate,
so the single initial scrollToBottom on conversation load/switch could land above
the true bottom once off-screen messages render at full height. On that path
spacerActive is 0, so ChatWindow's corrective ResizeObserver is inactive and the
action's own observer watches the h-full container that never resizes.

Add a bounded (max 5 frame) re-scroll on the instant scroll paths (initial mount
and conversation switch) that converges to the real bottom and bails early if the
user scrolls or we are already at the bottom. The smooth new-message path is
unchanged (ChatWindow's spacer observer already handles it).

Addresses PR review feedback.

Author: gary149

src/lib/actions/snapScrollToBottom.ts

@@ -96,6 +96,27 @@ export const snapScrollToBottom = (node: HTMLElement, dependency: MaybeScrollDep
 		}
 	};
 
+	const nextFrame = () =>
+		new Promise<void>((resolve) => {
+			if (typeof requestAnimationFrame === "function") requestAnimationFrame(() => resolve());
+			else resolve();
+		});
+
+	// content-visibility:auto messages start at their contain-intrinsic-size
+	// estimate, so a single scrollToBottom can land short of the true bottom: as
+	// the bottom messages scroll into view they render at full height and grow
+	// scrollHeight. Re-scroll across a few frames to converge, stopping early once
+	// we reach the bottom or the user takes over. Bounded so it can never loop
+	// indefinitely.
+	const scrollToBottomConverged = async (behavior: ScrollBehavior = "instant") => {
+		scrollToBottom(behavior);
+		for (let i = 0; i < 5; i++) {
+			await nextFrame();
+			if (isDetached || userScrolling || isAtBottom()) return;
+			scrollToBottom("instant");
+		}
+	};
+
 	const scheduleUserScrollEndCheck = () => {
 		userScrolling = true;
 		clearUserScrollTimeout();
@@ -176,7 +197,16 @@ export const snapScrollToBottom = (node: HTMLElement, dependency: MaybeScrollDep
 			clearUserScrollTimeout();
 
 			await tick();
-			scrollToBottom(getScrollBehavior(newDependency));
+			const behavior = getScrollBehavior(newDependency);
+			// Conversation switch/load uses "instant" and renders content-visibility
+			// messages from their size estimate; converge to the real bottom. The
+			// "smooth" path (new user message) is handled by ChatWindow's spacer
+			// observer, so keep its single smooth scroll.
+			if (behavior === "instant") {
+				await scrollToBottomConverged(behavior);
+			} else {
+				scrollToBottom(behavior);
+			}
 			return true;
 		}
 
@@ -284,7 +314,7 @@ export const snapScrollToBottom = (node: HTMLElement, dependency: MaybeScrollDep
 	if (dependency) {
 		void (async () => {
 			await tick();
-			scrollToBottom();
+			await scrollToBottomConverged();
 		})();
 	}
 

src/lib/components/chat/ChatMessage.svelte

@@ -374,7 +374,7 @@
 {#if message.from === "assistant"}
 	<div
 		bind:offsetWidth={messageWidth}
-		class="group relative -mb-4 flex w-fit max-w-full items-start justify-start gap-4 pb-4 leading-relaxed max-sm:mb-1 {message.routerMetadata &&
+		class="message-cv group relative -mb-4 flex w-fit max-w-full items-start justify-start gap-4 pb-4 leading-relaxed max-sm:mb-1 {message.routerMetadata &&
 		messageInfoWidth >= messageWidth
 			? 'mb-1'
 			: ''}"
@@ -552,7 +552,7 @@
 {/if}
 {#if message.from === "user"}
 	<div
-		class="group relative {alternatives.length > 1 && editMsdgId === null
+		class="message-cv group relative {alternatives.length > 1 && editMsdgId === null
 			? 'mb-7'
 			: ''} w-full items-start justify-start gap-4"
 		data-message-id={message.id}
@@ -686,6 +686,25 @@
 {/if}
 
 <style>
+	/* Long conversations render every message at once (no virtualization). On
+	   mobile WebKit each tab's renderer has a hard ~2 GB memory ceiling, and a
+	   few hundred messages worth of laid-out DOM + paint backing stores blows
+	   past it, so iOS Safari jetsam-kills the tab ("A problem repeatedly
+	   occurred"). content-visibility:auto lets the engine skip layout and paint
+	   for off-screen messages, keeping peak memory bounded. contain-intrinsic-size
+	   gives skipped messages a stable placeholder height so the scrollbar and
+	   scroll position stay sensible. content-visibility implies paint containment,
+	   which would clip the copy/retry/edit controls that sit just below each
+	   message (they overflow by up to ~44px); overflow-clip-margin extends the
+	   clip region so those controls keep painting. Browsers without
+	   content-visibility support simply ignore these rules (progressive
+	   enhancement). */
+	.message-cv {
+		content-visibility: auto;
+		contain-intrinsic-size: auto 200px;
+		overflow-clip-margin: 3rem;
+	}
+
 	@keyframes loading {
 		to {
 			stroke-dashoffset: 122.9;