Install the Windows service as the NT SERVICE virtual account only

--install-service now registers the service under
NT SERVICE\gpu-turnstile (low-privilege, per-service, no password) and
grants it modify access to the install dir (for self-updates) and the
LOG_FILE dir, plus read access to an external config file. Grants run
after CreateService because the virtual account's SID does not exist
before registration; a failed grant rolls back the registration.

SPEC.md

@@ -180,13 +180,16 @@ install|remove` does the same thing.
   it 5 s after any failure.
 - **Layout**: install to `C:\Program Files\gpu-turnstile\` (exe plus
   `gpu-turnstile.env`); logs belong in `C:\ProgramData\gpu-turnstile\` via
-  `LOG_FILE`. The service must be able to write its install directory for
-  self-updates — Program Files is writable by LocalSystem and admins, which
-  is why running as the default `LocalSystem` account is the simple choice.
-- **Account**: the default `LocalSystem` works out of the box. For least
-  privilege, create the service with the virtual account
-  `NT SERVICE\gpu-turnstile` and grant it write access to the install and
-  log directories only (no network logon, no user profile).
+  `LOG_FILE`.
+- **Account**: the service always runs as the virtual account
+  `NT SERVICE\gpu-turnstile` — a per-service low-privilege identity the
+  SCM manages (no password, automatic logon-as-a-service right, no admin
+  rights, gone when the service is removed). The installer grants it
+  modify access to the install directory (self-updates rewrite the exe)
+  and the `LOG_FILE` directory (created if missing), plus read access to
+  the config file when it lives elsewhere. The grants happen after service
+  registration because the virtual account's SID only exists from that
+  point on; if a grant fails the service registration is rolled back.
 - Use a config file (above) for the service — Windows services have no
   convenient environment. Logs go to `LOG_FILE` since there is no console.