fix: defer re-entrant publishes of the same event

[GuillaumeRx]

Explanation

Messenger delivered a re-entrant publish of the same event inline. When a subscriber published the event it was currently handling — directly, or indirectly through a delegated messenger (for example a stateChange subscriber that calls an action which triggers update() on the same controller) — the nested publish ran to completion, and then the in-progress publish resumed its subscriber loop and re-delivered its now-stale payload to the subscribers it had not yet reached. A downstream subscriber such as a UI store bridging controller state could therefore end up observing an older payload after a newer one.

This surfaced in the extension as a network filter that stayed on a just-added network even though the enabled-network map had already been restored: the restore's stateChange re-entered publish, and the stale "switched" payload was the last thing the UI received.

This change makes #publish defer a publish of an event that is already being published on the same messenger, then drain the deferred publishes in order once the in-progress publish finishes. Because the event stays marked as "publishing" while draining, further re-entrant publishes of that event are deferred and drained too. Re-entrant publishes of a different event still run inline. The fix covers delegated messengers as well, since delegated publishes funnel through the same #publish.

Note this is a small behavioral change: a re-entrant publish of the same event is now delivered after the current publish completes (still synchronously, within the same tick) rather than nested inside it.

References

• Related to chore: migrate addNetwork to LegacyBackgroundApiService metamask-extension#44142, where this was worked around at the call site (restoring the map outside the stateChange publish via await).

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

[Gudahtt]

LGTM!