Bug 692 - Header elements do not flow predictably

[denete]

What does this PR do?

When different screen resolutions / window sizes / device orientation changes are observed, the elements in the header display do not adapt in a predictable manner. This PR keeps the content visible, organized, and responsive, while moving the action buttons out of the header area. The action buttons have been moved to a panel which is triggered by a single hamburger menu button in the header. This minimizes the space taken from the header's content area.

The pop-over menu (hamburger menu) displays the project logo, version number running with info link, and the action buttons that were previously in the header.

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

How to test

In each layout...

1. Note the content in the header
2. Resize the window / change device orientation
3. Note the content stays visible
4. Select the hamburger menu, interact with each button

Checklist

• App loads without console errors
• Tested in Dark, Light, and Retro themes
• Responsive at different screen sizes (desktop + mobile)
• If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
• If adding an API route: includes caching and error handling
• If adding a panel: wired into Modern, Classic, and Dockable layouts
• No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
• No .bak, .old, console.log debug lines, or test scripts included

Screenshots (if visual change)

[denete]

This addresses #692.

[accius]

Good idea consolidating the header actions into a cleaner UI, especially for mobile and tablet. But on desktop this adds an extra click to everything and hides controls that power users hit constantly. A few things to address before merge:
Desktop shouldn't use the hamburger. Settings, Fullscreen, and Donate were all one-click buttons visible in the header. Now they're all behind a two-click hamburger menu on every screen size. For users who open Settings dozens of times a session, that's a real usability regression. The hamburger makes sense on mobile and tablet where header space is tight, but on desktop the buttons should stay inline. Use the existing breakpoint prop to switch between direct buttons (desktop) and hamburger (mobile/tablet).
Duplicate menu code. The hamburger menu + modal is copy-pasted nearly identically three times: Header.jsx, Classic compact, and Classic full. All three have the same logo, version display, button list, overlay, close handler, and escape listener. Extract it into a shared HeaderMenu.jsx component that all layouts import.
Debug artifact in Header.jsx. There's a backgroundColor: 'lightgray' on the header-content-column div. That'll paint a light gray bar across the header in every theme including dark.
z-index mismatch. The menu overlay is zIndex: 100000 in Header.jsx but zIndex: 10000 in ClassicLayout.jsx. Should be consistent. The DonateButton was bumped to 100001 to sit above the menu but that only works against the 100000 value.
HeaderMenu defined inside component body. In ClassicLayout, HeaderMenu is defined as a function inside the component, so it's recreated every render. Either pull it out as a standalone component or wrap it in useCallback/useMemo.
Confirm logo in production builds. public/img/ohc-logo-254x114.png works in dev, but verify it's accessible at /img/ohc-logo-254x114.png in the Docker production build since only dist/ and public/ (from the builder stage) get copied.