The menus, and what happens when you open/close them, do belong to Firefox. Cocoa gives apps a fair amount of power here. In Firefox's case, the issue is likely because each window specifies its own independent set of menu bar menus - very un-macOS - and it handles that by destroying and recreating the global menu bar every time you switch windows. The stuck menu bug seems to happen when a window is opened or closed, so my guess would be that something about the destroy-and-recreate routine is broken on macOS 27.
If Firefox isn't responsible for rendering the menu bar, then Firefox doesn't own the menu bar. It sounds like what you're describing is a process where Firefox tells the OS what items it wants the OS to put in the menu bar. Whether or not the app provides a new set of top-level menu entries during a window switch, it still seems to be entirely the responsibility of the OS to actually manage the rendering and respond to user interaction, including the OS keeping track of which top-level menu should be rendered as selected, and the OS should be enforcing that there's only zero or one selected menu.