refactor(helper): migrate to SMAppService for macOS 13+ helper install

[marxo126]

Why

SMJobBless was deprecated in macOS 13. As of macOS 26.4.1 the OS-level smd daemon now rejects SMJobBless installs that previously worked, silently breaking fan control for end users on the latest macOS:

```
smd: App "eu.exelban.Stats" did not pass helper check "eu.exelban.Stats.SMC.Helper".
```

Reproduces consistently on a fresh macOS 26.4.1 install — clicking Install fan helper silently fails, no helper files land at `/Library/PrivilegedHelperTools/`, and the popup keeps showing the placeholder forever. Affects every user who upgrades to macOS 26.

Change

Migrate the install/uninstall flow to the modern `SMAppService` API (macOS 13+) while keeping the existing SMJobBless code path intact as a fallback for macOS 11/12.

• New `SMC/Helper/eu.exelban.Stats.SMC.Helper.plist` — bundled launchd plist with `Label`, `MachServices`, and `BundleProgram` pointing to the helper binary at its existing `Contents/Library/LaunchServices/...` path (binary location unchanged).
• New `PBXCopyFilesBuildPhase` in the Stats target copies the plist to `Contents/Library/LaunchDaemons/` in the app bundle — where `SMAppService` daemons must live.
• `Kit/helpers.swift`:
  • `install(completion:)` branches on `#available(macOS 13.0, *)`. macOS 13+ calls `SMAppService.daemon(plistName:).register()`. Older macOS keeps the existing SMJobBless + `AuthorizationCreate` flow.
  • `uninstall()` branches to `service.unregister()` on 13+, helper-side XPC uninstall on older.
  • `isInstalled` queries `service.status` on 13+.
  • New `requiresApproval` computed property surfaces the SMAppService `.requiresApproval` status so the popup can show "approve in System Settings → Login Items & Extensions" guidance instead of the generic Install button. (UI wiring not in this PR — kept minimal; happy to add as a follow-up if you'd like the UX in the same change.)
• Helper code (`SMC/Helper/main.swift`) and existing `SMC/Helper/Launchd.plist` left untouched. The legacy plist is still consumed by the SMJobBless path.

User flow on macOS 13+

1. User clicks Install fan helper in the popup
2. `SMAppService.daemon(plistName:).register()` is called
3. macOS adds an entry to System Settings → Login Items & Extensions → Background Items, status `.requiresApproval`
4. User approves the toggle in System Settings
5. Daemon bootstraps, helper goes `.enabled`, fan control comes alive

Net diff

```
3 files changed, +89 lines net
SMC/Helper/eu.exelban.Stats.SMC.Helper.plist | +14 (new)
Kit/helpers.swift | +55
Stats.xcodeproj/project.pbxproj | +14 (PBXFileReference, PBXBuildFile, PBXCopyFilesBuildPhase, group children, build phase wiring)
```

Testing — important caveat

Compile-verified (`BUILD SUCCEEDED`, plist lands at `Contents/Library/LaunchDaemons/eu.exelban.Stats.SMC.Helper.plist` in the built bundle). Direct API probe of `SMAppService.daemon(plistName:).register()` against the dev build returns `SMAppServiceErrorDomain code 3 — Codesigning failure loading plist (-67028)`, which is the expected rejection of unsigned dev builds — `SMAppService` strictly requires a Developer ID signature.

Behavioural verification therefore requires a Developer ID-signed build, which I don't have locally. The PR is filed as Draft so you can build with your signing cert, register the daemon once, and confirm the user-side flow (System Settings prompt → approval → helper bootstraps).

If the registration call succeeds and the System Settings approval prompt appears, the migration is good. If `register()` throws on a properly-signed build, the most likely culprits are:

• Plist filename mismatch — the file in the bundle must be exactly `eu.exelban.Stats.SMC.Helper.plist` (the file is named that way in the source and the Copy Files phase preserves it).
• Helper not actually present at the `BundleProgram` path inside the bundle.
• Notarization needs to include the new plist (no extra resource, but worth a sanity check on the first signed build).

Happy to iterate on any of the above.

Pre-13 fallback

`installSMJobBless()` and the older uninstall path are unchanged — verbatim from main. Any users on macOS 11/12 see no behavioural difference.

[marxo126]

Status — API contract verified via direct probe; runtime behaviour blocked on Developer ID Application cert.

What was tested

1. Compile + bundling — BUILD SUCCEEDED, eu.exelban.Stats.SMC.Helper.plist lands at Contents/Library/LaunchDaemons/eu.exelban.Stats.SMC.Helper.plist in the built bundle, matching what SMAppService.daemon(plistName:) looks for.
2. API contract probe — wrote a minimal Swift CLI that calls SMAppService.daemon(plistName: "eu.exelban.Stats.SMC.Helper.plist").register() from inside the dev build's bundle context. Result:

   SMAppServiceErrorDomain code 3
   Codesigning failure loading plist: eu.exelban.Stats.SMC.Helper.plist code: -67028
   

   This is the expected rejection of an unsigned bundle — SMAppService reaches the cert-validation step (so the plist path, file presence, and API call are all correct), then refuses because the bundle isn't signed with a Developer ID Application cert. An Apple Development cert (free Apple ID) is also rejected with the same code; only a paid Developer ID will satisfy SMAppService.
3. Pre-13 fallback path — installSMJobBless() is a verbatim copy of the pre-existing flow; no changes to the legacy code, only branching.

What CAN'T be tested without a Developer ID

• The actual register() success → requiresApproval status → user approval in System Settings → daemon bootstrap chain. That requires a properly-signed build. My Apple Developer Program account is pending Apple's approval (submitted, awaiting); when the cert lands I will post a recorded trace of the full flow in this PR.
• In your build environment (already Developer-ID-signed by RP2S87B72W), register() should succeed on first call. The daemon will land in requiresApproval state and show in System Settings → Login Items & Extensions → Background Items pending user approval.

Maintainability notes

• The legacy SMJobBless path is untouched and continues to handle macOS 11 / 12. Wholly conditional on if #available(macOS 13.0, *).
• New helper plist is bundled via a new PBXCopyFilesBuildPhase (dstPath = Contents/Library/LaunchDaemons). Visible in Xcode → Stats target → Build Phases.
• New SMCHelper.requiresApproval property is available for the popup to show "approve in System Settings" guidance instead of the generic "Install fan helper" text — wiring that into popup.swift is a small follow-up I'm happy to add if you want the UX in the same change.
• The helper's own Info.plist SMAuthorizedClients is irrelevant to SMAppService (harmless); intentionally left in place for the SMJobBless fallback.

Why this matters

smd on macOS 26 silently rejects SMJobBless installs with "did not pass helper check" (full repro in #3193). Without an SMAppService migration, fan control is broken for every macOS 26 user regardless of the rest of the fan-control direction. This PR is independent of #3189 / #3190 / #3191 and useful even if you decide to keep fan control in maintenance-only mode.

References #3193.

[marxo126]

Closing — won't pursue upstream. Thanks for Stats, used it long-term and learned a lot from the codebase. Work continues on personal fork at marxo126/stats for own M4 Max use only.

[exelban]

hi, sorry but as I say I'm more and more convinced to drop the fan support, so most probably all theses PRs have no much sense. That said, this one is something I'm definitely more interested in, and I'll most likely take a closer look at the implementation. Thanks for your time!

[marxo126]

hi, sorry but as I say I'm more and more convinced to drop the fan support, so most probably all theses PRs have no much sense. That said, this one is something I'm definitely more interested in, and I'll most likely take a closer look at the implementation. Thanks for your time!

Thanks and no worry, I will contitue working in my fork until everything tested and worked well with my developer account then I will let to you know for test if good or not.