fix: open the tail container through the filter in LargeInventoryTests

[henrywang]

Closes #182

Cause

testLargeInventorySupportsNavigationAndLifecycleWorkflows scrolled the 100+ row compute list with three scroll(byDeltaX: 0, deltaY: -10_000) calls, waited for computeRow-container-099 to be hittable, then clicked it. XCUITest's synthetic scroll on that list doesn't settle. Measured locally:

• In one run, the three scrolls never reached the bottom, even after a 2s settle.
• In a failing run, the list reached the bottom with the row visible (hittable at 0s and 2.3s), then drifted about 1900pt back up within 2.5s. Every row then reported a degenerate frame, which is the {{0, 768}, {0, 0}} CI signature ({{0, 1107}, …} locally).

The click came 0.3s after the hittable check, so it raced that drift.

Ruled out along the way:

• Mock data changing: MockContainerService has no refresh timer.
• App focus: activating Finder and then Berthly left the row in place in two clean runs.
• A product bug: nothing in the app scrolls the compute list programmatically, so I found no evidence that real users see the jump.

Fix

Open container-099 through the existing compute filter, as the test already does for machine-018. There is no scroll left to race. A comment in the test records the measurements so the scroll isn't reintroduced.

Coverage change: the test no longer exercises scrolling a long list. That was the unreliable part, and the filter is how a user reaches a deep row in a 100+ item list.

Verification

• Locally on macOS 27: the fixed test passed 15 of 15 consecutive runs (-test-iterations 15 -run-tests-until-failure). Before the fix it failed on the 1st or 2nd run on the same machine. The other LargeInventoryTests test also passed 15/15.
• swiftlint lint --strict clean.
• CI history before the fix: 6 failures, 5 on the macOS 27 leg and 1 on the macOS 26 leg.

🤖 Generated with Claude Code