test(editor): measure the scroll view's reservation against the insets AppKit already reported

[datlechin]

main is red on Package Tests. #2891 merged before that job reported, and it is the change that
made this test fail:

✘ "The floating views' widths go on top of the scroll view's own insets"
    Expectation failed: (insets.bottom → 25.0) == (8 → 8.0)
    Expectation failed: (insets.right  → 59.0) == (42 → 42.0)

Both are exactly 17 higher: the room AppKit reserves for legacy scrollers, on the two edges that
have one. top and left were unaffected and passed.

Cause

The test asserts absolute inset values, which silently assumes the scrollers contribute nothing.
The suite's init sets scrollView.scrollerStyle = .overlay to get that, and on the runner it
does not hold: the clip view still comes back with legacy room on the trailing and bottom edges.

Nothing about the production behaviour changed, and nothing about this test changed either. #2891
moved nine suites into this target, and the same test passes on #2893, which did not. It is the
absolute expectation that was never safe, not the reservation it is checking.

Fix

The claim in the test's own name is that the floating views' widths go on top of whatever the
scroll view already had, so it now reads the clip view's insets first and asserts the delta. That
is the shape the sibling test legacyScrollerRoomIsKept in the same file already uses, and it
holds under either scroller style:

let computed = clip.contentInsets
scrollView.floatingSubviewInsets = HorizontalEdgeInsets(left: 70, right: 40)
#expect(clip.contentInsets.left  == computed.left  + 70)
#expect(clip.contentInsets.right == computed.right + 40)

swift test --package-path Packages/TableProEditor --force-resolved-versions: 336 + 153 cases,
0 failures.

No CHANGELOG entry: tests only.