fix: fallback to user launchd domain on macOS

[jescalan]

Summary

On macOS, Hermes currently assumes launchd commands should always target gui/<uid>. That works from GUI-attached shells, but it fails in some background/user-session contexts where launchctl print gui/<uid> returns Domain does not support specified action even though the per-user launchd domain is available.

This change makes launchd domain selection probe both domains and choose the first one that is actually accessible:

• prefer gui/<uid> when it is available
• fall back to user/<uid> when the GUI domain is not accessible
• preserve the historical gui/<uid> default if probing is inconclusive

Testing

Added targeted coverage for the domain-selection helper:

• returns user/<uid> when gui/<uid> is unavailable but user/<uid> works
• keeps gui/<uid> as the fallback when both probes fail

Impact

This makes hermes gateway start and related launchd operations more reliable across macOS execution contexts without changing behavior for the normal GUI-attached case.

[teknium1]

Thanks for the macOS launchd investigation. This is an automated hermes-sweeper review; the requested behavior is now implemented on current main.

• hermes_cli/gateway.py:3524 probes gui/<uid> and then user/<uid>, with a Background/SSH-safe user/<uid> fallback at hermes_cli/gateway.py:3586.
• tests/hermes_cli/test_gateway_service.py:1399 covers the exact gui-unavailable/user-available case, alongside GUI preference, managername fallback, and caching coverage.
• The implementation landed in a8f404b29fa9ffde4ba4763e2bc30a077f430fa0 (fix(gateway): probe launchd domain instead of hardcoding user/<uid> (#40831)), following the superseding macOS launchd work in merged PR fix(gateway): user launchd domain + Background session, detached fallback (macOS 26) #40581.

Closing as implemented on main.