[WRONG BRANCH] fix(windows): remove native WinSW service during fresh scheduler install

[luvs01]

Motivation

• Prevent a lifecycle regression where a fresh Task Scheduler install could leave an existing WinSW native service registered, causing two managers to own/respawn the proxy and create stale/duplicate service state.

Description

• Extracted the WinSW removal and re-verification transaction into removeNativeWindowsServiceForScheduler() and reuse it from the existing native installer path.
• Wire the helper into the fresh Task Scheduler installer so the native WinSW service is removed after manager/proxy stop but before publishing assets or starting the scheduler task.
• Added a removeNativeService test seam to FreshWindowsSchedulerInstallDeps and updated unit tests to assert the new ordering and that failed native-service removal triggers rollback of the newly-registered scheduler task.

Testing

• Ran the focused lifecycle tests with bun test tests/service.test.ts --test-name-pattern 'fresh Windows scheduler install gets|fresh scheduler install rolls back' and they passed.
• Ran type checking with bun run typecheck and it passed.
• Attempted the full test suite with bun run test, but the environment could not complete the GUI build due to external registry downloads returning HTTP 403, so the full-suite run was environment-blocked (not a behavioral regression in these changes).

---

Codex Task

[coderabbitai]

Warning

Review limit reached

@luvs01, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 18 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: a10b94a1-312e-4c10-a974-1d4c91bc4099

📥 Commits

Reviewing files that changed from the base of the PR and between 1193075 and 1085b20.

📒 Files selected for processing (2)

• src/service.ts
• tests/service.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

✅ Deterministic PR hygiene checks passed.

[github-actions]

⏳ DRAFT

• wrong target branch (main); retarget to dev.

What to do

• Retarget this PR to dev — all contributions go to dev.

Its title has been prefixed with [WRONG BRANCH].
This pull request was already a draft. Its draft status will be preserved after every issue above is resolved.