test: hardware verification backlog for the all-smi service subcommand (#309, #310, #311)

## Background

#309 (PR #319), #310 (PR #321) and #311 (PR #320) landed the `all-smi service` subcommand for systemd, launchd and the Windows Service Control Manager. All three issues are CLOSED and carry `status:done`, correctly: the code is written, integrated, and dispatched from the shipped binary on every platform.

What is not done is verification. 19 acceptance criteria across the three issues were deliberately left unticked because they need hardware or environments that were not available during implementation: no systemd host, no dpkg, no Windows machine, no authorization for root-level macOS changes, and no access to push the production Homebrew tap. Every one of those gaps is recorded honestly in the corresponding PR body, and none of them is a code defect.

The problem is location. Those 19 unticked boxes now live inside three CLOSED issues, which nobody opens and no filter surfaces. This issue is the single open place that survives, so the work is not silently forgotten when the environments become available.

This repository already has a directly comparable gap: #306's "verified on a physical Intel Mac" criterion has been unmet since 2026-08-05, with no separate tracker. The follow-ups that were filed (#307, #308) cover different work, not the verification itself. This issue exists so the service subcommand does not repeat that.

## Split status: complete

The 16 items that used to live here as groups A through D now live in four independent issues, one per environment that unblocks them. Each child carries its group's full checklist and all of its verification notes, so nothing about what was and was not verified was lost in the move.

| Group | Issue | Unblocked by |
| --- | --- | --- |
| A | #354 test: verify the systemd service path on a Linux host with dpkg (#309) | A systemd Linux host with dpkg, ideally a plain Ubuntu VM. |
| B | #355 test: apply and verify the service block in lablup/homebrew-tap (#310) | Push access to `lablup/homebrew-tap`. |
| C | #356 test: verify the launchd system scope on macOS with root and a reboot (#310) | Root on any Apple Silicon Mac plus one reboot. |
| D | #357 test: verify the Windows SCM service backend on a Windows machine (#311) | A Windows machine, or the self-hosted `windows-on-macmini02-x64` runner with `ENABLE_WINDOWS_SERVICE_SMOKE` set. |

Why the split: the four groups are unblocked by four unrelated environments and are independently actionable. Holding them in one issue meant none of them could be scheduled, assigned, or closed independently, so whoever gained access to one environment could not close anything. #357 carries `priority:high` because nothing in the Windows backend has ever been executed or even linked, which makes it the largest unverified surface of the three platforms.

This issue stays open as the umbrella, so the work keeps a single surviving home until all four children are resolved.

## Scope

Three of the 19 items are already tracked by #330, which covers the `systemd-service` CI job's system-scope lifecycle path never having executed. Those three are **excluded** from all four child issues so the trackers do not overlap:

- The `kill -9` crash-restart check.
- The tarball system-scope install flow (`sudo all-smi service install --now`, then `uninstall` leaving no unit).
- `/etc/all-smi/config.toml` being honored by a running daemon.

That leaves the **16** items now distributed across #354, #355, #356 and #357.

## Acceptance Criteria

- [x] Every box in groups A through D is either ticked with evidence (a command transcript, a CI run link, or a screenshot), or split out into its own issue with a stated reason for splitting. Satisfied by the split: #354, #355, #356 and #357, each stating the reason.
- [ ] All four child issues are closed. That is what closes this issue.
- [ ] When a criterion in a child is verified, the corresponding box is also ticked on the original issue, so #309, #310 and #311 end up truthful rather than permanently understating what was delivered. Each child carries this criterion for its own group.
- [ ] Any degradation found during verification is filed as its own issue and linked from the child that surfaced it, rather than being absorbed into a checkbox comment.

## References

- Children: #354 (group A, systemd), #355 (group B, Homebrew tap), #356 (group C, macOS system scope), #357 (group D, Windows SCM)
- Issues: #309 (Linux systemd), #310 (macOS launchd), #311 (Windows SCM), #330 (systemd CI system-scope path, owns the three excluded items)
- PRs: #319 (systemd implementation), #320 (Windows SCM implementation), #321 (launchd implementation), #323 (launchd smoke test readiness gate), #331 (technical reports and the `brew install` clarification), #313 (Intel tap stanza, still unapplied)