fix: emit the service status metric immediately on Start

[joshiste]

Summary

• Start() was a no-op, so the first stackstate_service_status metric only appeared after the first Status() poll (one CallInterval, i.e. 1s, after the check started).
• Start() now reuses the same status-check logic as Status(), so the first metric is emitted immediately when the check starts.
• Updated the e2e runServiceCheck helper: it previously asserted RunAction() always succeeds and only expected failures from Wait(). A deviating state present from the very beginning now fails at RunAction() itself, since Start() runs the check immediately.

Test plan

• go build ./...
• go test ./extservice/...
• go test -run TestWithMinikube ./e2e/... (all 7 cases pass, including fail-early-disabled and at-least-once)

[claude]

Claude finished @joshiste's task in 5m 15s —— View job

---

Review: fix: emit the service status metric immediately on Start

• Check previously unresolved review threads for fixes (none exist on this PR)
• Review diff in extservice/service_check.go
• Review diff in e2e/integration_test.go
• Post review feedback

No bugs, security, or concurrency issues found. I verified the change against the actual action-kit-go SDK/e2e-client source (via steadybit/action-kit) rather than just reading the diff in isolation:

• Start() now reuses MonitorStatusCheckStatus, whose domain-level failures are carried via StatusResult.Error → copied into StartResult.Error. In the e2e test client, startAction() treats a non-nil StartResult.Error as a hard failure and returns it from RunAction() before entering the Status() polling loop — exactly matching the PR's described behavior and the updated runServiceCheck helper.
• action_kit_api.StartResult has no Completed field (confirmed from the generated API types), so correctly only Artifacts, Error, Messages, Metrics are copied from the StatusResult — nothing is silently dropped that the type could carry.
• The e2e helper change (e2e/integration_test.go:99-111) registers defer action.Cancel() before checking err. This is safe: RunAction()'s underlying client always returns a valid (non-nil) *actionExecutionImpl{} even on error, so there's no nil-pointer risk.
• Traced all four testServiceCheck* scenarios against the new Start() logic (immediate fail-early, fail-early-disabled-with-recovery, at-least-once ignoring fail-early) — each remains correctly satisfied by the new code path, including the "at least once" mode which is unaffected since FailEarly only applies to statusCheckModeAllTheTime.
• State (DeviationTitle, StatusCheckSuccess) mutated during Start() is correctly threaded forward into subsequent Status() polls via the returned State field, so there's no double-counting or lost state between the two calls.

No concerns to flag on code quality, performance, or typos either — the change is small, correctly scoped, and well covered by the updated e2e test.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud