[Flyout System] Fix body padding when overlay flyout is subsequent to push flyout

[tsullivan]

Summary

Closes elastic#9159

The fix makes push padding conditional on managed state and active ownership. Only the active push flyout applies body padding, and as soon as it becomes inactive (e.g., when an overlay flyout takes over), the code synchronously clears that padding and its related CSS variable. Moving the padding logic into useLayoutEffect ensures the body is updated before paint and before any measurement by scroll-lock utilities, eliminating race conditions and layout shifts.

Additionally, the changes coordinate scroll locking with push state. A mutation observer tracks whether push padding is present; overlay flyouts only enable scroll lock when no push padding remains. This prevents conflicts between push and overlay sessions, guarantees the page is “unpushed” when switching to overlay, and avoids visual flicker or inconsistent measurements.

Screenshots

• Before

  

• After

  

Checklist

• This was checked in mobile
• This was checked in IE11
• This was checked in dark mode
• Any props added have proper autodocs
• Documentation examples were added
• A changelog entry exists and is marked appropriately
• This was checked for breaking changes and labeled appropriately
• Jest tests were updated or added to match the most common scenarios
• This was checked against keyboard-only and screenreader scenarios
• This required updates to Framer X components

[github-actions]

👋 Since this is a community submitted pull request, a Buildkite build has not been started automatically. Would an Elastic organization member please verify the contents of this pull request and kick off a build manually?

[tsullivan]

Replacing with elastic#9207