* Chat: stop a message delete from re-rendering the whole thread

Deleting one message from a long chat cost 98ms at 25K characters of thread
content and 472ms at 300K, growing 4.8x across that range. The cost was
attributed to the export / rebuild / import round trip in
delete-thread-message.ts. Profiling says otherwise: sampled on Chromium at 300K
characters (220 messages, 43,422 DOM nodes), deleteThreadMessage is 1.8ms of a
498ms delete, and the whole of syncExportedRepositoryToBackend under it is
1.3ms. The other 400ms is one synchronous React render, and the reason it is
that big is that deleting a message re-rendered every remaining message.

Two things caused that, both here rather than in the repository code.

ThreadPrimitive.Messages rebuilds its element array whenever the message COUNT
changes, so every message's wrapper re-renders on a delete. assistant-ui absorbs
that with a bail-out: an element with no props is memoized and the same object
is handed back, and React skips reconciling it. The `components={{...}}` form
never reaches it, because what the render prop returns there is
<ThreadMessageComponent components={...} />, whose props object is freshly
allocated on every render. Rendering through the children form, returning one
shared propless element, means the wrapper re-renders and the message body,
action bar and tooltips underneath it do not. The role and edit-state selectors
are the ones assistant-ui's own ThreadMessageComponent uses, and the component
choice reproduces its getComponent fallback chain for the three components this
thread supplies.

useOwnsResearchMessage selected `thread.messages`, which subscribed every user
message's action bar to every thread change, and then answered its question by
exporting the whole repository once per message. It now selects the answer, so a
change that does not move the answer re-renders nothing, and the export is
shared across the messages at one revision instead of repeated per message. The
question needs the repository rather than the visible list, since a research
reply can sit on a branch the view is not showing, so the export stays.

Measured with the heavy-thread harness from #9016, chromium, three interleaved
A/B rounds, each cell the median of 3 repetitions:

    25K chars    98.3ms -> 25.9ms
    100K chars  206.5ms -> 34.7ms
    300K chars  472.3ms -> 63.5ms

Growth across the range falls from 4.80x to 2.45x. Firefox at 300K goes 615ms ->
58ms. DOM node counts, message counts before and after the delete, console
warnings and stray requests are identical at every size, so what changed is how
much of the tree React walks, not what it produces.

test_deep_research_frontend_contract pinned the exact expression the ownership
question used to be written as. It is repointed at the question and its scope
rather than at the expression.

* Tighten the comments added by this change

---------

Co-authored-by: danielhanchen <danielhanchen@users.noreply.github.com>

Two conflicts, both unions, nothing dropped from either side.

- studio/frontend/tsconfig.app.json: main added smoke-heavy-thread-main.tsx to
  include, this branch added smoke-thread-weight-main.tsx. They are separate
  entry points and both files exist, so both entries are kept. Dropping either
  would leave one smoke entry out of the typecheck.
- tests/studio/test_autoscroll_harness_contract.py: main imports types, this
  branch imports ast. Both are kept because both are used.

This branch does not read quiet() or quietUntilIdle(), so #9016's change to what
they return does not move any number measured here. The heavy-thread harness
that does read them arrived with this merge and is main's own.

Suite is 3954 passed, 4 skipped. The 71 failures in test_chat_autoload_failure_gate.py
and test_model_picker_contracts.py reproduce identically on a clean checkout of
main at 0775936, so they are not from this branch and are deselected above
rather than papered over.

…rebuilding all of them first (unslothai#9058)

* Studio: stop a long thread rebuilding every message before it can paint

* Measure the shift as a residual, and skip a frame the reader scrolled through

The correction was measured in document space, following LibreChat#14901. In our
viewport that double-corrects: Chromium's own scroll anchoring has usually already
moved scrollTop by the inserted height, and adding the full insertion on top of it
walked a detached reader 22,897 -> 117,104 and dumped them at the bottom of the
thread. Viewport space measures the residual instead, which is single-digit pixels.

That exposed the other half: across the transition-deferred gap the reader's own
wheel is indistinguishable from a layout shift in viewport space, so a 4000px scroll
during a widening was cancelled inside the frame. The hook now counts user gestures
and the correction skips any frame one landed in.

Found by tests/studio/probe_progressive_anchor.py, added here.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Arm the window on the cold open, and stop leaning on the browser for the scroll correction

Four fixes, each with a measurement behind it.

1. The cold open never armed. ProgressiveMessages mounts before the history adapter
   has delivered anything, so the useState initialiser ran at count 0, declined, and the
   whole thread then landed in one unbounded commit. Measured in the app: mount at count
   0, count 220 about 160ms later, same resetKey, first paint carrying all 220 rows. The
   window now re-arms on the commit that first fills an empty tree. Gated on the previous
   count being zero rather than on crossing MIN_PROGRESSIVE_MESSAGES, so it cannot window
   a conversation the reader is already in the middle of. 300K, chromium, medians of 5:
   cold open 2498.8ms/220 rows to 270.6ms/16 rows, against a base of 2536ms.

2. The scroll correction assumed the engine had already done the work. It measured the
   anchor in viewport space, which reports the residual left by CSS scroll anchoring, and
   dropped any frame the reader gestured through on the grounds that the residual is
   single-digit pixels. Both hold only where the engine anchors. WebKit implemented scroll
   anchoring in February 2026, so every shipping Safari and every iOS browser today does
   not, and Playwright's WebKit 26.5 does, which is why this was invisible. Measured at
   150K with overflow-anchor:none forced on the viewport: one dropped frame walked a
   parked reader 19,259px, and dropping every frame walked them 45,873px, on all three
   engines. The correction is now a tested pure function that picks its space from a
   one-off feature probe: viewport-space residual where the engine compensates, document
   space where it does not, and no frame is dropped in the second case. Same fixture with
   the fix: 12px and 13px.

3. A thread that shrank under a live window painted nothing. The row loop clamped start
   to count, which makes it emit zero rows. Measured: dropping a 220-message thread to 10
   while the window sat at start 204 painted an empty column for 2 to 8 frames on all
   three engines. The window is dropped in that commit instead.

4. completeProgressiveMounts sampled the completer set once, and the completers register
   from an effect, so a caller in the same task as the open returned on an empty set with
   16 of 220 rows in the document. It now re-reads the set across frames, registers from a
   layout effect, and resolves on the commit that actually dropped the window rather than
   on a two-frame timer started at the call.

Also resets adjustImplRef in the autoscroll teardown alongside the other two impl refs.

Tests: the correction is now testable arithmetic, with both branches covered. The glue
assertions read comment-stripped source for their positive matches too, so commenting the
feature out no longer leaves them green, and every source slice requires both of its
markers instead of silently widening to the end of the file. npm test 3514 passed,
typecheck, build and biome clean.

* Count every scroll the hook did not make, and resync even when the correction is zero

Two more paths where the scroll correction reads the wrong thing, both raised in review and
both reproduced here.

A scrollbar drag, PageUp, the arrow keys and middle-click autoscroll reach the autoscroll
hook as nothing but a scroll event. They detach the reader through onScroll's 2px
accumulator, but they never bumped the user-gesture counter, which only onWheel and
onTouchMove touched. A correction measured across one of them therefore read the reader's
own movement as a layout shift and reversed it. onScroll now counts any scroll with a
non-zero delta. The two scrolls that are not gestures stay excluded by arithmetic rather
than by a flag: the corrective write advances lastScrollTop with itself, and a native
scroll-anchoring adjustment is advanced past by the resync below, so both arrive with
delta 0.

And a widening that native scroll anchoring absorbed in full needs no scroll write, but
the browser still moved scrollTop by the whole inserted height and still fires a scroll
event for it. Measured on a 400px scroller with 2000px inserted above the scroll position:
one scroll event carrying the new offset, on Chromium 151, WebKit 26.5 and Firefox 153.
The old early return left lastScrollTop a whole insertion behind, so that event arrived as
a large downward scroll nobody made, and a reader who had deliberately detached within the
24px re-attach threshold, which detachFromBottom puts them at whenever the composer grows,
was silently re-attached and yanked to the bottom on the next widening. The mount window
now reports every widening including the zero ones, and the hook resyncs its bookkeeping
whether or not it wrote.

npm test 3516 passed, typecheck and build clean.

* Do not believe an empty completer set until it has been looked for

completeProgressiveMounts re-read the set across frames but still returned at the first
empty reading, so the one case it was rewritten for stayed broken: a caller in the same
task as a cold open finds the set empty because the history load has not finished, and two
animation frames is nowhere near the roughly 160ms that load takes. The remaining passes
never ran, because the loop exited on the first pass.

An empty set is now only believed after 400ms of looking, while a set that has been
non-empty and has since drained is believed immediately. A caller on a settled thread
therefore pays 400ms, which is the right direction to be wrong in: the alternative is a
screenshot or an export of a conversation that is not there yet, and anything reading the
whole thread out of the DOM is already doing something far more expensive.

npm test 3516 passed, typecheck and build clean.

* Take the browser out of the scroll correction instead of trying to predict it

The correction measured the residual left by CSS scroll anchoring and dropped any frame the
reader had scrolled through, on the grounds that the residual is single-digit pixels. That
is true exactly while the browser compensates, and this code was not in charge of whether
it did. Two ways it does not, both measured at 150K characters on the 9016 fixture:

- No shipping Safari and no iOS browser has scroll anchoring at all today. WebKit
  implemented it in February 2026 and Playwright's WebKit 26.5 has it, which is why this
  was invisible here. Standing in for those builds with overflow-anchor:none, one dropped
  frame walked a parked reader 19,259px and dropping every frame walked them 45,873px, on
  all three engines.
- Anchoring is also suppressed per frame on engines that do have it, including after a
  programmatic scroll, which is what a scrollbar drag, PageUp, the arrow keys and
  middle-click autoscroll all become. On Chromium 151 with anchoring available and a reader
  scrolling that way through the build-in: 45,161px of drift, because those frames were
  both uncompensated and skipped. Counting those scrolls as gestures, which is what the
  previous commit did, made this worse rather than better: it added skips to frames that
  needed the correction most.

No measurement taken inside the frame can tell a compensated frame from a suppressed one,
so the browser is taken out of the loop rather than modelled. The viewport sets
overflow-anchor:none for as long as the mount window is open and gets it back the moment
the window closes, so a settled thread is exactly the thread that shipped before. With
nothing else moving scrollTop, the correction is document space, which subtracts the
reader's own movement arithmetically instead of dodging it, so no frame is ever skipped.
That removes the feature probe, the gesture counter and the whole notion of a skipped
frame. This is the shape LibreChat#14901 uses.

Measured on the same fixture and reader, native anchoring available, all three engines:

  parked reader           12px drift (chromium), 6 to 13px (webkit)
  scrollbar or keyboard   4,081 to 4,226px (chromium), all of it the reader's own scrolling
                          against 45,161px before
  continuous wheel        4,612 to 4,852px (chromium), 4,489 to 4,819px (webkit), likewise
                          their own scrolling

npm test 3514 passed, typecheck, build and biome clean.

* Measure the anchor against its scroll container, and settle waiters when the thread goes away

Three more from review.

getBoundingClientRect().top is measured against the window, so it also moves when the
scroll container moves, and this container moves for reasons that have nothing to do with
the thread: the composer grows a line, the mobile browser chrome slides away, a parent
relayouts, the window is resized. Any of those landing between the capture and the widening
commit read as content inserted above and were corrected away, moving a detached reader for
no reason. Both ends now go through one sampleAnchor that subtracts the container's own top.

completeProgressiveMounts awaits a promise this component resolves from an effect. If a
thread switch or a navigation unmounted the component first, the layout effect's cleanup
removed the completer from the set but left that promise pending forever, so a DOM capture
that raced an unmount hung rather than completing. Outstanding waiters are now flushed on
unmount, and the ref is emptied by the flush rather than by the effect that schedules it,
so a cancelled frame leaves them to be settled rather than dropping them.

probe_progressive_anchor.py cannot run on this branch, because it drives 9016's fixture and
9016 is not merged. It now exits with a message naming the three files it needs instead of
a bare ModuleNotFoundError. Not fixed by vendoring a copy of the harness: two copies of a
measurement harness is how the two copies stop agreeing, and this probe's numbers are only
comparable to 9016's while there is exactly one of it.

npm test 3515 passed, typecheck, build and biome clean.

* Disarm native anchoring at capture time, not from a layout effect

The layout effect that set overflow-anchor:none on the viewport did not run in time, and
the window it left open was the worst possible one: the first one.

This component is a descendant of the viewport element, so on the commit that mounts them
both, React runs this subtree's layout effects before the viewport's own ref callback.
viewportRef.current is still null, the style is silently skipped, and it only lands on the
next commit, which is the first widening. Measured on that version: computed overflow-anchor
stayed auto from the first painted row at +305ms until the first widening at +803ms, so that
widening ran with anchoring live and the document-space correction was applied on top of the
browser's own. A reader who scrolled 4000px inside that window was left 776px short of where
they parked, and one whose whole gesture landed inside it was carried back to 24px from the
bottom of a 118,004px thread. Neither happened on the merge base.

The style is now set in the same requestAnimationFrame that captures the anchor, immediately
before the sample it would otherwise invalidate. That frame runs after a paint, so the ref is
populated by definition, and it is by construction before any widening rather than merely
soon. The layout effect keeps only the restore, and an unmount cleanup restores it too.

Measured after, 300K, chromium, three repetitions, the reader's whole 4000px gesture landing
inside the first mount window while 110,625px of content is inserted above them: parked at
4000px from the bottom, ends at 4028px, worst single frame 4px. The merge base under the
same gesture never widens at all and holds 4000px.

npm test 3623 passed, typecheck, build and biome clean.

* Hold still the row the reader can see, and compensate the intervals between widenings

Two findings from review, one of which turned out to be the other's cause.

Disabling native scroll anchoring for the whole mount window means nothing absorbs a
relayout above the fold that is not a widening: Streamdown replacing a pre when Shiki
finishes highlighting it, KaTeX resizing a formula, an image landing. The autoscroll hook
does not cover it either, because its mutation path pins a following reader and
deliberately leaves a detached one alone. Measured by injecting a 600px height change into
one row above a detached reader while the window was open: the reader moved the full 600px,
against 0px on the merge base where native anchoring absorbed it. The correction now also
runs between widenings, one frame later than the movement, which is invisible for a single
reflow and is what keeps it to one getBoundingClientRect and one scrollTop read per frame.

The first attempt at that measured nothing, and the reason is the second finding. The
anchor was the first row in the list rather than the first row the reader can SEE. Widening
prepends above everything, so for a widening any row will do; a relayout does not, because
a row growing between the topmost row and the fold moves the reader while leaving the
topmost row exactly where it was. Both paths now hold the first visible row, and that
improved the widening correction too: the whole-gesture-inside-the-first-window case, three
repetitions at 300K with 110,625px inserted above a reader parked 4000px from the bottom,
goes from 28px of drift and a 4px worst frame to 0px and 0px.

tests/studio/probe_progressive_reflow.py is the probe that found it, included with its own
guards, since both of the things it initially got wrong produced a confident clean zero.

npm test 3625 passed, typecheck, build and biome clean.

* Drop a window that is past the end instead of narrowing it back to a chunk boundary

A window whose start is at or past the end of the thread already causes every row to be
rendered, because the row map falls back to no restriction. The STATE was left saying start
204 though, so the next widen clamped to count and subtracted a chunk: against a thread that
had shrunk to 100 messages that is start 68, and rows 0 to 67, which the previous commit had
just mounted, are unmounted again. Nothing in this design is allowed to unmount a row, and
this was the one path that did.

Fixed at both levels, because they protect different things. widen now returns null for any
window at or past the end, which is a property the state machine can hold on its own and is
covered by a test that asserts monotonicity for every reachable window and count rather than
for one example. And the glue reconciles the stale state during render instead of leaving it
for the next frame, so the committed state matches the tree that was committed with it.

npm test 3627 passed, typecheck, build and biome clean.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Close four gaps in the between-widenings compensation

All four are in the sampler added a commit ago, and all four have the same shape: with
native anchoring off for the duration of the mount window, anything that moves content above
a detached reader and is not seen here is kept by the reader in full.

A widening now hands the sampler a post-correction baseline instead of nulling it. Nulling
meant the next frame merely re-picked and re-based, so an image or a Shiki block landing
between the widening's layout effect and that frame was folded into the new baseline and
never corrected.

Visibility is tested by the anchor's own box rather than by its top offset. A row taller
than the viewport, scrolled just past, can have its top within a viewport of the fold while
none of it is on screen, and a reflow between it and the first visible row then moves the
reader while leaving it still.

The anchor descends to the fold rather than stopping at the row. A reader partway through a
long answer has that row's top ABOVE them, so an image or a code block earlier in the same
message moves everything they can see and leaves the row's top exactly where it was. The
descent is bounded at eight levels and runs once per re-pick, not per frame.

And a shrink the browser already clamped is no longer corrected twice. Content above a
reader near the bottom shrinking is the one case where the browser still moves scrollTop
with anchoring off, because the offset they were at stops existing. The document-space delta
reports the whole shrink regardless, so the sample now carries the container's maximum
scrollTop and the correction subtracts what the clamp already absorbed.

Re-measured at 300K on chromium, three repetitions each, all against a reader parked 4000px
above the bottom: a 600px reflow injected above them nets to 0px; the whole 4000px gesture
landing inside the first mount window while 110,625px is inserted above them ends at exactly
4000px with a 0px worst frame; and 9016's own anchor probe, 94,207px inserted, reports 0px
drift and a 0px worst frame.

npm test 3635 passed, typecheck, build and biome clean.

* Never leave a frame without a baseline, and keep the row as a fallback anchor

Two more gaps in the same sampler, both raised in review.

An anchor that leaves the viewport was cleared and re-picked on the NEXT frame, which leaves
a frame with no baseline, and a reflow landing in it is folded into the new baseline and
kept by the reader. It is now re-picked and sampled in the same tick. That is the same
mistake as nulling after a widening, in a second place.

And the widening correction dropped itself whenever the captured node had been replaced
since the capture. That became much more likely with the descent added a commit ago: the
anchor is now often the very pre element Streamdown replaces when Shiki finishes
highlighting it, and a transition-deferred widening leaves plenty of room for that to
happen. Since anchoring is off, dropping the correction moves a detached reader by a whole
chunk of prepended rows. The row the anchor sits in is now captured alongside it and used
when the anchor is gone; a data-role row is not replaced in place by anything.

Re-measured at 300K on chromium, three repetitions each: 9016's own anchor probe reports 0px
drift and a 0px worst frame with 94,207px inserted above a reader parked 4000px from the
bottom, and a 600px reflow injected above them nets to 0px.

npm test 3635 passed, typecheck, build and biome clean.

* Say what the fold descent does not cover, so the bound is known

Review asked for a caret point at the fold to cover lines reflowing inside a single tall leaf
block. Declined, and the reasoning belongs next to the code rather than only in a thread: the
residual is one paragraph's height change, for a detached reader, during the few hundred
milliseconds a window is open, and the fix costs an engine-conditional per-frame measurement
whose own correctness is harder to check than the element-based one.

* Give the idle sampler the same fallback and the same re-basing the widening path has

Two more from review, both places where the between-widenings sampler was missing something
the widening path already had.

It kept no stable fallback. When Streamdown replaces the held pre after Shiki finishes
highlighting it, the sampler re-picked and re-based AFTER the replacement's own reflow, so
with anchoring off the reader kept that height change. It now holds the row alongside the
anchor, exactly as the widening capture does, and corrects from the row when the anchor is
gone. One holdAnchor builds both, so the two paths cannot drift apart.

And it returned early on a frame with nothing to correct, which left the baseline's scrollTop
at wherever the reader was several frames ago. anchorCorrection's clamp term reads that
scrollTop, so a later shrink near the bottom had the wrong amount subtracted from it. The
baseline is now re-based on every frame, correcting frames and no-op frames alike.

Re-measured at 300K on chromium, three repetitions each: 9016's own anchor probe reports 0px
drift and a 0px worst frame with 94,207px inserted above a reader parked 4000px from the
bottom, and a 600px reflow injected above them nets to 0 or 1px.

npm test 3657 passed, typecheck, build and biome clean.

* Say why the row is the fallback rather than a point below the replaced block

Review asked for a stable point below the replaceable content instead of the message row.
Declined, and the reasoning belongs next to the code: an anchor below the replaced block
would catch its height change, but it would also catch the block growing downward past the
fold, which does not move anything the reader is looking at. That trades an error in the
common case for one in a rarer case. The residual either way is one code block's height
change, for a detached reader, during the few hundred milliseconds a window is open.

* Drop the useMemo import this change added to thread.tsx and never used

* Stop citing an edge probe that is not in the tree

* State what the clamp term cannot know about a reader scrolling through a shrink

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Studio: size the first mount commit against the shortest rows, not a fixture

INITIAL_MESSAGES was documented as "roughly eight viewports of overscan",
which is true of unslothai#9016's fixture and of nothing else: that fixture's messages
are large. The number that decides whether the first commit can paint a gap is
how tall 16 of the SHORTEST rows are, and that is now measured.

A one-word message is 103px in this thread, so 16 of them are 1639px, and with
the viewport's 48px top inset and 165px bottom spacer the first commit fills
every viewport up to 1890px of clientHeight. Measured on a 144-message thread
whose last 24 messages are one-word replies, Chromium 151 / Firefox / WebKit:
0px of gap at 900, 1080, 1440, 1800, 1840 and 1860px. Above 1890px it does
undershoot -- 10px at 1900, 110px at 2000, 270px at 2160, for 287 to 499ms
until the first widening chunk closes it -- and the merge base paints nothing
at all for 1318ms on the same fixture, so that is left as the trade it is.

probe_compact_tail_gap.py is the probe. Stated plainly rather than implied: it
CANNOT RUN on this branch as it stands. It drives smoke-heavy-thread.html,
which lives in unslothai#9016 and is not merged, and it needs two methods that harness
does not have yet, seedCompactTail(chars, tailMessages) and gapMetrics(). It
names both in a preflight check rather than failing as a bare JS error, and
its docstring says so. This is the same dependency probe_progressive_anchor.py
and probe_progressive_reflow.py on this branch already carry, so it is the
shape this branch has already settled on rather than a new one. The two
methods are being folded into unslothai#9016 so the probe becomes runnable there; the
fixture used to take these measurements is deliberately not duplicated here,
since copying it would fork 767 lines of an unmerged harness.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Quote the compact-row heights as the pair they are, not their average

The doc comment gave a one-word row as 103px. That is the MEAN of the two
heights these rows actually have: 126px for a user row and 80px for an
assistant row, which differ in padding. Sixteen rows, eight of each, are
1643px rather than the 1639px the average produced.

The floor of 1890px is unaffected, because INITIAL_MESSAGES is even and the
average is exact on a balanced set. The reason to correct it anyway is that
rows-times-103 is wrong by up to 23px at an odd count, so anyone recomputing
the floor after changing INITIAL_MESSAGES would get a number that looked
derived and was not. Measured on the harness in unslothai#9016 by its owner while
landing seedCompactTail.

* Record that the idle anchor sampler no longer reproduces its own measurement

The comment claimed that without this effect a detached reader kept the full
600px of an injected height change. Re-measured, that no longer happens:
ablating the whole effect leaves grow 600, grow 3600 and shrink 1200
identical to head within noise.

The logic is not wrong, the ordering is. The widening capture effect is
declared first, so React registers its rAF first on every commit and its
callback runs before this one's, leaving anchorRef.current non-null on every
frame the window is open. This body returns at its first line: instrumented,
0 of 1110 frames across chromium, firefox and webkit got past it. Confirmed
causally by swapping only the two effect declarations, after which it runs
about 5 times per repetition.

Kept rather than deleted, because the widening path it defers to has no
visibility test, so this is the only thing that would catch a reflow on a
frame with no widening pending. The comment now says so, and says that
reordering those two effects switches it on.

* Tighten the progressive-mount comments

Same explanations, fewer lines. Every measured number, the anchoring rationale and the unexercised-branch warnings are unchanged in substance.

* Write the compact-tail probe's reports as utf-8

The three write_text() calls used the platform default encoding, which is
cp1252 on Windows, so a report gaining a non-ASCII byte would fail there and
nowhere else. tests/test_source_read_encoding.py gates exactly this and was
red on Repo tests (CPU).

* Tighten the progressive mount comments

Same code, shorter prose. Collapses the multi-paragraph blocks in
progressive-mount-controller.ts, progressive-messages.tsx and the two
progressive-mount test files to the point each was making, and drops
restatements of what the code already says. Every measured figure the
constants rest on is kept.

* Studio: close three progressive-mount assertions that could not fail

The mutation matrix over the mount window had five ablations no assertion
caught. Three were real holes, all the same shape: an assertion matched the
whole file where the invariant belongs to one effect, so a second occurrence
elsewhere in the file kept it green.

- The widening step is now required to be scheduled on a frame INSIDE the
  widening effect. A timer there runs before the commit it follows has painted,
  so the anchor capture samples the previous layout and the viewport ref the
  disarm needs is not populated yet, and the cleanup cancels a frame, so a
  window closed between the commit and the callback would widen anyway.
- Restoring overflow-anchor is now required in the effect that runs on the
  CLOSING commit, not merely somewhere in the file, where the unmount cleanup
  was satisfying it alone. Without the close path native anchoring stays off
  for the rest of the thread's life with nothing compensating, since both
  corrections stop with the window.
- The completer search interval is now required to be a positive constant that
  outlasts a cold open's history load. Sampling with a zero deadline keeps both
  previously asserted lines and still returns on the first pass, which is the
  read-once failure again.

Each is red on exactly the ablation it names and green here. The remaining two
ablations change no behaviour: one edits only a comment, and the other disables
a sampler that declaration order already keeps from running.

* Studio: size the progressive mount's first commit on rows that render

The initial tail was chosen by counting messages, but a message whose role
the thread supplies no component for paints nothing: threadMessageKind
returns "none" and ThreadMessage renders null, so the row has no height.

Both importers preserve the system role (chat-import.ts,
openwebui-import.ts), so an imported conversation whose last 16 messages are
system entries opened on sixteen zero-height rows and no conversation at all
until a later widening frame rescued it, which is the stall this window
exists to remove rather than cause.

Size the tail by walking back until it holds a full tail of renderable rows.
Renderability comes from threadMessageKind through the new rendersAsRow, so
there is no second list of roles to drift from the renderer. Reaching further
back only ever mounts more, so the window still only widens. A thread with
fewer renderable rows than one tail is not windowed at all.

The predicate is read imperatively off the store, not through useAuiState: a
selector touching the messages array runs on every store write, which would
walk the thread once per keystroke and once per streamed token.

* Studio: bound the progressive mount's first commit, and measure the reopen paint floor

Sizing the first commit on renderable rows walks back across every message
that does not render, and that walk was unbounded: sixteen visible messages
followed by two hundred system entries walked to index zero, so the commit
rebuilt every provider in the thread. That is the bound this window exists to
create, so cap the span at four tails. A thread has to be three quarters
non-rendering across its whole tail before the cap binds; below that the
window is exactly the renderable-row one. When it does bind the first commit
shows whatever renders inside the cap and widening reaches the rest within a
few frames, which is bounded either way.

The heavy-thread smoke declared a fixed floor of one double-rAF wait for
'reopen ms'. That was right while the tail arrived in a single commit. The
mount window brings a long thread back over several frames, and 'reopen ms'
runs until the message count is whole, so it now spans one wait per commit:
one at 25K and ten at 100K. Read the count the reopen loop already reports
instead of declaring it, and resolve the declaration per row so a hand
written literal is still caught when it drifts.

* Studio: leave no style attribute behind when the mount window hands scroll anchoring back

removeProperty empties the inline declaration but keeps the attribute, so a converged
viewport carried style="" where the shipping one carries no style at all. Inert, but it
was the only difference a whole-document structural digest could find between this branch
and its merge base at 100K and 300K: 45,014 normalized lines, one changed line, against a
null control that scored exactly zero. Byte-identical is worth being able to state rather
than footnote.

Both hand-back paths now go through one helper, and the test asserts there is no second
removeProperty outside it, so a future path cannot reintroduce the residue.

* Studio: keep the progressive mount's frames in the reopen convergence metric

`reopen ms` had its paint floor read from the run: `_floor_from("reopen",
"paintWaits")` subtracted one ~33ms vsync floor for every double-rAF wait the
poll loop paid. That is right only while the wait count is a property of the
instrument. It is not. The loop polls in the same rAF queue as the application's
own commits, so on a build that brings a long thread back over several animation
frames the count is a property of the APPLICATION: 1 on a single-commit rebuild,
and 1 at 25K, 8 at 100K, 24 at 300K on a progressive mount.

So the subtraction was asymmetric between the two arms of a comparison and grew
with the axis being varied. On the 220-message fixture it removed 33.3ms from
the single-commit arm's 300K cell and 796.8ms from the progressive one's, which
turned a reopen that is 6.8% slower into one that reads 28.7% faster, and turned
a 25K -> 300K curve that rises faster than the single-commit build's (7.60x
against 7.08x) into one that rises slower (5.07x). A floor removes a constant
the instrument adds; the moment it tracks the thing being measured it stops
being a floor and starts being the measurement.

Only the observation floor comes out now, and it is a constant: reopen is driven
by a React state update, so the count check straight after openThread() always
still sees the unmounted tree and the loop always waits out exactly one paint
before a finished reopen can be observed at all. Every wait past that one is a
frame the application spent committing rows and stays in the number.

`reopen wall ms` had the same defect through the generated wall axes, which take
the recorder window's measured `paint_waits` (2 -> 25 across the ladder on head).
WALL_FLOOR_OVERRIDES pins reopen to its two terminal observation waits, one per
loop, and leaves every other action on the measured count, where those waits
really are the harness idling between driven steps.

`paintWaits` is still reported and still checked, now as a lower bound rather
than as equality: subtracting a floor the metric never waited out is the failure,
paying more waits than are subtracted is the normal state of a progressive mount.

---------

Co-authored-by: danielhanchen <danielhanchen@users.noreply.github.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: danielhanchen <unslothshared@gmail.com>
Co-authored-by: oobabooga <112222186+oobabooga@users.noreply.github.com>