[Experimental] Probe: what macOS 27 exposes for hiding menu-bar icons (#360/#366)

[talkstream]

Draft / exploration — does NOT hide anything. A read-only probe + findings to
scope a real macOS-27 hide mechanism for the managed-overflow epic (#366). No merge
expected; opened for the maintainer's evaluation. Companion to #370 (detect-and-degrade),
which is the correct shipping behavior on macOS 27 until such a mechanism is designed.

Why

#370 establishes that the length-inflation trick is dead on macOS 27 and degrades
gracefully. The obvious next question — can Hidden Bar actually hide icons on macOS 27,
and at what cost? — is exactly what Option D / #366 ("managed-overflow, likely via
Accessibility") needs answered before any design. This PR is that recon, run on real
macOS 27 hardware (build 26A5368g).

experiments/macos27-menubar-probe.swift is a standalone, non-target tool (kept out
of the app build on purpose, so the sandboxed/MAS posture and #370 stay untouched). It
only reads state — it never moves, presses, hides, or modifies anything.

swiftc experiments/macos27-menubar-probe.swift -o /tmp/mbprobe && /tmp/mbprobe

Findings (macOS 27.0, 26A5368g)

1. MenuBarAgent owns the bar; per-item windows are gone. The public
   CGWindowListCopyWindowInfo list shows a single full-width Window Server menu-bar
   window — none of the per-item status CGWindows the old trick (and window-capture
   tools) depended on.

2. Accessibility still enumerates items + positions.
   AXUIElementCreateApplication(MenuBarAgent).AXExtrasMenuBar returns the 5 foreign
   status items with readable positions — but only with Accessibility permission
   (AXIsProcessTrusted), which the App Sandbox forbids.

3. ...but there is no public lever to hide/move/reorder them.

   owner	role / subrole	AXPosition settable	actions
   MenuBarAgent (modern)	AXGroup / AXHostingView	false	none
   SystemUIServer (legacy)	AXMenuBarItem / AXMenuExtra	false	AXPress, AXCancel

   The modern items are read-only SwiftUI hosting views: no settable position, no actions.

Conclusion

On macOS 27 public APIs let you read the menu bar but not rearrange it — there is no
public-API hide mechanism. Real hiding requires a private path (SkyLight/CGS* or the
MenuBarAgent interfaces that the maintained tools reverse-engineered), which needs
Accessibility (non-sandbox, not MAS-shippable as-is) and is explicitly at risk of Apple
changing/blocking it during the beta.

Suggested path (for #366)

• Reference implementation that already hides on macOS 27 Golden Gate: stonerl/Thaw
  (MIT, maintained Ice fork; see its #687) — new menu-bar API + Accessibility, non-sandboxed.
• In-repo UI starting points: Show hidden items in a separate bar #358 (separate hidden-items bar), feat: Notch Overflow — access menu bar icons hidden behind the camera notch #350 (notch overflow).
• If pursued here, isolate the hide module behind a build flag (e.g. EXPERIMENTAL_MENUBAR_27)
  and a separate non-sandboxed target so the default build / macOS 27: detect hide-mechanism failure and degrade gracefully (#360) #370's posture stay clean.

Full write-up: docs/experiments/macos27-menubar.md. Re #360, #366.