Auto merge of #25158 - jdm:wr-spatial-panic, r=SimonSapin

Fix "Tried to use SpatialId before it was defined" layout panic

In the case where an element uses `text-overflow: ellipsis` and causes overflow, we create a TruncatedFragment that wraps the original overflowing fragment. When collecting stacking contexts for the truncated fragment, https://github.com/servo/servo/pull/18510 addressed the case where the wrapped fragment wouldn't be processed, but neglected the case where that fragment ends up creating a new stacking context. When that happens, the TruncatedFragment would be stuck with the updated scrolling/clipping information based on the new stacking context, but it would be a child of the parent stacking context. Since the new scrolling/clipping nodes do not exist in the display list until the new stacking context display item is created, this led to the observed panic.

---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #24895 and fix #19281 and fix #22826.
- [x] There are tests for these changes

components/layout/display_list/builder.rs

@@ -606,9 +606,15 @@ impl Fragment {
                 true
             },
             // FIXME: In the future, if #15144 is fixed we can remove this case. See #18510.
-            SpecificFragmentInfo::TruncatedFragment(ref mut info) => info
-                .full
-                .collect_stacking_contexts_for_blocklike_fragment(state),
+            SpecificFragmentInfo::TruncatedFragment(ref mut info) => {
+                let _ = info
+                    .full
+                    .collect_stacking_contexts_for_blocklike_fragment(state);
+                // To ensure the caller updates this fragment's stacking context
+                // appropriately based on the un-truncated fragment's status,
+                // we don't pass on the result of collecting stacking contexts.
+                false
+            },
             _ => false,
         }
     }