fix: ensure custom traffic lights float to top

[codebytere]

Description of Change

Closes #29541.

Fixes an issue that surfaced as a result of 8bf66f8, where custom traffic lights could show underneath a BrowserView (e.g. wouldn't always be floated to the top of the view hierarchy). This fixes that.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed an issue where custom traffic lights could be covered by BrowserViews on macOS.

[zcbenz]

Removing/adding a view is a high cost operation, it is not appropriate to do in RedrawTrafficLights, which is frequently called in events unrelated to browser views.

Also RedrawTrafficLights is not invoked when browser view is added/removed, this fix probably only worked because there were some window events happened to occur. So I think we should add a new helper function to reorder buttons_view_ and only call it when necessary.

[codebytere]

@zcbenz i think that should do it!

[release-clerk]

Release Notes Persisted

Fixed an issue where custom traffic lights could be covered by BrowserViews on macOS.

[trop]

I was unable to backport this PR to "13-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I have automatically backported this PR to "14-x-y", please check out #29628

[trop]

@codebytere has manually backported this PR to "13-x-y", please check out #29663