Keep infinite-scroll observer when WIP cut line splits the list

What does this MR do and why?

On a board list with a WIP limit, items are rendered in two loops split by the WIP cut line: the items before the cut line, then the cut line, then the items after it. The infinite-scroll GlIntersectionObserver is attached on every sixth item, keyed off each loop's own index via isObservableItem(index).

The problem is that the after-cut-line loop restarts its index at 0. So when the split leaves only 4–6 items before the cut line and the rest after it, neither loop ever reaches index 6: the before-cut-line loop is too short, and the after-cut-line loop's index has been reset. No observer is rendered, onReachingListBottom never fires, and scrolling fails to load the remaining items.

The fix offsets the after-cut-line index by the number of items before the cut line — isObservableItem(beforeCutLine.length + index) — so observer placement is continuous across both loops, exactly as if the list were a single sequence. Lists without a cut line are unaffected (beforeCutLine.length is effectively the full list and the after-loop is empty).

Changelog: fixed

Before: on a list whose WIP cut line leaves ~4–6 cards above it, scrolling to the bottom never loads the remaining cards (no intersection observer is mounted).

After: the observer is mounted continuously across the cut line, so scrolling loads the rest of the list as expected.

(Attaching a before/after screen recording of scrolling such a list.)

How to set up and validate locally

1. Run the board list specs:

The added case ("intersection observer with a WIP cut line") sets maxIssueCount: 4 with more issues than that, so the cut line splits the list, and asserts both the cut line and at least one GlIntersectionObserver render.

2. In GDK, open an issue board and set a list's WIP limit so the cut line lands with roughly 4–6 cards above it and several more below it (more cards than the limit). Scroll to the bottom of that list and confirm the remaining cards load. On master they do not; with this change they do.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related issues

Closes #633115 (closed)