docs(changelog): first-response jump scroll-settle fix (#6621)

CHANGELOG.md

@@ -5,6 +5,8 @@
 
 ### Fixed
 
+- **Jumping to the first response no longer snaps back to the bottom while the answer is still streaming.** When you tapped "jump to answer" on the first response, the view scrolled to the answer but then got yanked back down as more of the response streamed in, so you couldn't read from the top. The jump now takes ownership of the scroll position and holds it where you put it — it only releases when you explicitly scroll down, press End, or switch sessions. Normal bottom-following (when you haven't jumped) is unchanged. Thanks @pxxD1998. (#6621)
+
 - **A provider that hit its credit limit (HTTP 402) recovers in ~2 minutes after you top up, instead of staying greyed out for an hour.** When a pay-as-you-go provider returned 402 (Payment Required), the WebUI marked it unavailable for a full hour, so even after you added credits it stayed unusable for up to 60 minutes. The WebUI now derives the 402 cooldown from the installed agent runtime's own credential-pool contract rather than hard-coding it, so its "is this provider usable yet" decision always matches what the runtime will actually lease (no window where the UI offers a provider the runtime still refuses). On a runtime that ships the shorter 402 cooldown the wait drops to ~120s; on an older runtime it safely keeps the previous one-hour behavior. Thanks @webtecnica. (#6626)
 
 - **Editing your transcript (truncate, retry, or undo) no longer risks the deleted messages coming back.** When you intentionally shrink a conversation, the on-disk session ends up with fewer messages than its `.bak` sidecar — and the session-recovery inspector used to read that as suspected data loss and recommend restoring the backup, resurrecting the messages you just removed. The session now stamps a one-time provenance marker whenever you deliberately shrink a transcript, and recovery treats a valid, current marker as "this shrink was on purpose" and leaves it alone. The marker is validated strictly (a malformed or missing marker fails closed to the original data-loss safeguard), and a genuine loss — where the backup is newer than your last intentional edit — still triggers recovery exactly as before. Thanks @franksong2702. (#6954)