#21212: fix: detect and manage systemd system services (rebased)

### Description This PR enables OpenClaw to detect and manage services when they are running as systemd **system** units (e.g., in `/etc/systemd/system/`). Currently, OpenClaw primarily assumes a **user** unit configuration. This is particularly useful for: - Production deployments on VPS/Servers where OpenClaw runs as a dedicated system service. - Environments where `systemctl --user` is unavailable or restricted. - Users who prefer standard system-wide service management. Addresses #1179 ### Changes - **Service Detection:** Updated `readSystemdServiceExecStart` to check both user-level and system-level unit paths. - **Service Control:** Added `sudo` support for `stop` and `restart` actions if a user unit isn't found, ensuring system services can be managed. - **Runtime Info:** Enhanced the runtime state to include an `isSystemService` flag and better error reporting for missing units. - **Availability Checks:** Added `isSystemdSystemServiceAvailable` to verify systemd access. ### Testing - Verified detection of system-level services on Linux. - Confirmed `stop`/`restart` commands correctly route to `sudo systemctl` when necessary. - Validated that existing user-service functionality remains unaffected. ### AI-Assisted PR Checklist - [x] **Marked as AI-assisted:** Yes, developed by Moss (OpenClaw Assistant) with human guidance from @growthringsadvisory. - [x] **Testing Degree:** Fully tested on a live OpenClaw instance running as a systemd system service. - [x] **Prompts/Logs:** Logic derived from a multi-turn debugging session to identify cross-user/system unit paths. - [x] **Human Confirmation:** I, @growthringsadvisory have reviewed the code and confirm it performs as described without side effects. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds support for detecting and managing systemd system services (in `/etc/systemd/system/`) in addition to the existing user service support. The implementation follows a fallback pattern: attempts user service operations first, then falls back to system services with `sudo -n`. **Key changes:** - `readSystemdServiceExecStart` now checks both user and system unit paths - Service control operations (`stop`, `restart`, `isEnabled`, `readRuntime`) try user services first, then system services with sudo - Added `isSystemService` flag to runtime state for distinguishing service types - Updated log hints to show correct `journalctl` commands based on service type - Tests updated to reflect the new user/system service distinction **Considerations:** - The `sudo -n` flag requires passwordless sudo configuration for system service operations - Error handling gracefully degrades when sudo access is unavailable - All service control functions maintain backward compatibility with existing user service workflows <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with minor considerations around sudo configuration - The implementation is well-structured with proper fallback handling and maintains backward compatibility. The code follows existing patterns in the codebase. One minor consideration: `sudo -n` requires passwordless sudo, which may cause silent failures for users without this configuration. The error handling is correct, but user experience could be improved with better error messaging when sudo authentication is required. - No files require special attention - all changes follow consistent patterns _{Last reviewed commit: e1d8070} <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->