fix(Android, Stack v4): Clear supportActionBar on fragment removal to prevent ScreenStackFragment leak

[t0maboro]

Description

Detected retention chain:

• AppCompatDelegateImpl.mActionBar
• ToolbarActionBar.mDecorToolbar
• ToolbarWidgetWrapper.mToolbar
• DebugMenuToolbar.config
• ScreenStackHeaderConfig.mParent
• Screen.fragment

ScreenStackHeaderConfig.onUpdate calls activity.setSupportActionBar(toolbar) on top screen updates. AppCompatDelegateImpl stores the resulting ToolbarActionBar in mActionBar for the lifetime of the activity. When a screen is popped (and the new top screen does not install a replacement ActionBar) the stale ToolbarActionBar is never released.

In onDestroyView of ScreenStackFragment, call reset SupportActionBar to release it and the fragment. I'm storing a reference to actionBar that ensures the call is skipped when the incoming screen has already installed its own toolbar in onUpdate.

Closes: https://github.com/software-mansion/react-native-screens-labs/issues/1129

Changes

• added a reference to the actionBar in ScreenStackHeaderConfig to clear actionBar only if it's associated with that fragment and wasn't overridden by other screen
• added onDestroyView override in ScreenStackFragment that will clear the ActionBar
• changed setToolbar signature to pass a CustomToolbar, which allows for storing the header config - HeaderConfig is nulled by React transaction before FragmentManager sends onDestroy to ScreenStackFragment

Before & after - visual documentation

Before	After
before.mov	after.mov

Test plan

Test3867

Checklist

• Included code example that can be used to test this change.
• For visual changes, included screenshots / GIFs / recordings documenting the change.
• For API changes, updated relevant public types.
• Ensured that CI passes

[kligarski]

Looks good.

I might've found another leak:

Screen.Recording.2026-04-13.at.12.58.31.mov

But I guess that it might be unrelated to this PR.

[t0maboro]

Looks good.

I might've found another leak:

Screen.Recording.2026-04-13.at.12.58.31.mov
But I guess that it might be unrelated to this PR.

This one might be the result that we have some nested stacks, which screens aren't displayed at this time, but I'll check #3855 because that one might help here. I had a similar case when using JS tabs https://github.com/software-mansion/react-native-screens-labs/issues/1130 but in that one there are 3 paths and the main problem is that these Screen instances are attached in the view hierarchy all the time.

To sum up, if that PR with freeing fragmentWrapper is sufficient, I think we may try to proceed in that one, but if in your case, all resources will be deallocated when you'll go back to the 1st screen - this isn't memory leak, rather an issue in our Model (especially in detachScreen method) that we're trying to remove fragments instead of detaching them.