Native service management (rsigma engine service)

[mostafa]

Summary

Add rsigma engine service <install|uninstall|start|stop|restart|status> over a shared ServiceBackend trait for systemd, launchd, and Windows SCM. Install idempotently bootstraps missing dirs, user, config template, binary, and unit, but never overwrites existing config, rules, or state.

Motivation

Running the daemon as a persistent service today means hand-writing units and path layouts. A first-class lifecycle group removes that friction for bare-metal and laptop installs while keeping operator-owned config safe across upgrades.

Proposed approach

• Feature-gated behind daemon; shared action driver plus per-platform backends and a mock backend for tests.
• System vs user layouts auto-selected by privilege with --system/--user overrides.
• Install: create missing paths/user, copy binary if needed, write config template only if absent, write unit only when content differs, enable, optional health self-test against /healthz.
• Hardened systemd unit (dedicated user, ProtectSystem, ReadWritePaths for state, Restart=on-failure).
• Uninstall preserves data; --purge removes config/rules. Status uses normalized vocabulary with JSON output.

Out of scope

• Kubernetes deployment (Helm/operator).
• Overwriting or migrating existing operator-authored config.

Tasks

• ServiceBackend trait, path layouts, CLI wiring under engine service
• systemd backend (system + user)
• launchd backend (LaunchDaemon + LaunchAgent)
• Windows SCM backend and service-dispatcher entry
• Golden unit/plist tests and mock-backend driver tests
• Docs: cli/engine/service and deployment guide

References

• Config discovery and rsigma config init template
• Daemon /healthz endpoint
• Rustinel service-management shape as prior art for the trait/command surface