WindowHeaderHost

The chrome/navigation window-feature's GLUE half — §ACW-7.1.

In the namespace octomy::window. Declared in src/libs/libwindow/window/WindowHeaderHost.hpp.

Detailed description

The chrome slice splits three ways (owner decision 2026-09-10): the `ActivityHeader` interface stays in `libactivity`, the reusable widget family lives in `libheader`, and THIS class is the only piece that knows about the standalone host. It wires an app-supplied header — any `ActivityHeader`, placed wherever the app chose — into an `ActivityStack`:

• the stack drives the header (title follows the active activity, back visibility follows depth) via ActivityStack::setDefaultHeader, which already existed for NodeNavigation;
• the header's back click, after the stack's own up-target handling (§AS-N-3), pops the stack — the same default every node window implements by hand — unless setBackPopsStack() turned it off;
• the header's menu click is relayed as openMenu(), because menu CONTENT is the app's, never this feature's.

Deliberately owns no placement: the header may sit on a `QToolBar`, a top-of-window widget, or construct's slot. A feature that mounted its own widget would be a framework; the decided shape is a library.

Note: §ACF-5 classification: **GLUE** — host chrome wired at build time, no lifecycle tier, living in the host-glue lib. No `Service`, no `ServiceLevel`.

Note: Ownership: the header is shared with the stack (which holds it as default header); the stack is held by `QPointer` and every slot no-ops once the host destroys it, rather than dereferencing freed memory.