fix(template): keep scroll offset when using keepScrolledIndexOnPrepend - #1896

The scroll strategies only compute a rendered range once `containerRect$`
emits, and that stream was fed exclusively by a `ResizeObserver`. The
observer delivers its first entry only when the browser produces a
rendering frame. A viewport created in a hidden or fully occluded tab
(chrome classifies a covered window as invisible) therefore never
received a container size and rendered nothing at all - permanently,
until the tab became visible again.

Measure the container synchronously in `ngAfterViewInit` and seed
`containerRect$` with it. Layout reads are available regardless of frame
production, and the ResizeObserver keeps the value up to date from there.

Co-Authored-By: Claude Fable 5 <[email protected]>

Prepending items shifts the rendered range by exactly the amount of
inserted items, which leaves the rendered slice identical. The
IterableDiffer reports no changes, so rendering bailed out through
`NEVER` - but every view now maps to a new index and has to be
re-positioned, leaving the list drawn at stale offsets.

Detect that case and re-render the views in place.

Two details matter for the strategies consuming these events:

- the batch handed to `renderingStart$` names every view index, because
  every view emits `viewRendered$` right after. An empty batch makes the
  strategies' position pass fast-forward its running cursor past views
  that still emit afterwards, stacking them at the end of the content -
  visible as a blank viewport with gaps between items.
- `viewRendered$` carries the view container index, not the context
  index. The two diverge as soon as `range.start > 0`.

Co-Authored-By: Claude Fable 5 <[email protected]>

`keepScrolledIndexOnPrepend` compensated the scroll position by counting
how many items were inserted before the anchor. That breaks as soon as
the update is not a pure insert - a chat client showing a transient
"loading older messages" row performs an insert *and* a remove, leaving
the list shifted by the height of that row (#1857).

Locate the anchored item again instead, via `trackBy`. That nets out
inserts, removals and moves ahead of the anchor in one pass, and shifts
by the resulting delta so the anchor keeps its sub-item offset - scrolling
to the top of the new anchor index is what produced the reported jump.

Further correctness fixes found while validating the above:

- when the anchored item itself disappears (the anchor sits *on* the
  transient row, which happens whenever the user waits at the very top),
  fall back to the nearest following survivor rather than bailing out.
  Bailing left the viewport pinned to the top, which in a reverse
  infinite scroller retriggers loading forever.
- autosize resolves the item index of a view through the trackBy cache
  instead of `view.context.index`. A second emission rebuilds the size
  ledger while a render or ResizeObserver pass for the previous dataset
  is still in flight, and the stale index booked measurements onto the
  neighbouring item. Since sizes are cached, that corruption was
  permanent and showed up as overlapping items and gaps while scrolling.
- `waitForScroll` is decided against the scroll target *clamped* to the
  scrollable bounds. A scroll the browser cannot perform emits no scroll
  event, so an out-of-bounds target latched `isStable` to false forever
  and froze rendering with a stale loading row on screen.
- autosize applies the range shrink independently of the relocation, so
  a transient row that was both the anchor and the last item of the
  rendered range no longer wedges a pending `scrollToIndex`.
- render and measure passes tolerate indices of a superseded dataset
  instead of dereferencing a removed ledger entry.

Adds cypress coverage for all of the above across the fixed, dynamic and
autosize strategies, including the render-without-ResizeObserver-frames
and range-shift cases from the preceding two commits.

Co-Authored-By: Claude Fable 5 <[email protected]>

Make the demo behave like an actual chat client so it exercises the
prepend compensation the way real consumers do:

- a transient "loading older messages" row inside the list while a
  history request is in flight, toggleable, plus a slower simulated
  backend so that state is actually observable
- history requests are driven by user input (wheel upwards, or arriving
  at the very top) rather than by range emissions. Passive scroll
  changes - the initial scroll, prepend compensations, measurement
  corrections - all report a range starting at 0 and would otherwise
  chain-load without any interaction. Wheel events are debounced to one
  trigger per gesture, since trackpad momentum keeps emitting for
  seconds after the flick.
- the batch runs dry at the beginning of the conversation instead of
  refetching the first page forever

Co-Authored-By: Claude Fable 5 <[email protected]>