status: distinguish API down from unreachable (#170)

## Summary

Splits the failure handling for `kernel status` so the message
accurately reflects what happened, instead of collapsing both transport
errors and non-2xx responses into one ambiguous "Could not reach Kernel
API" line.

Three failure cases now:

- **Transport error on `/status`** (network down, DNS, timeout) → `Could
not reach Kernel API. Check https://status.kernel.sh for updates.`
- **Non-2xx from `/status`, `/health` also unhealthy** → `Kernel API is
down. Check https://status.kernel.sh for updates.`
- **Non-2xx from `/status`, `/health` returns 200** → `Kernel API is
responding but /status is unavailable. Check https://status.kernel.sh
for updates.`

The `/health` probe matters because `/status` has an upstream dependency
on incident.io, so a 5xx from `/status` doesn't necessarily mean the API
itself is down. `/health` is a dependency-free liveness check on the
same server, so a 200 there confirms the API is up and only the status
endpoint is broken.

No new helpers, no synthetic UI rendering — reserves the dotted status
UI for real data from the API (same convention the dashboard's status
indicator follows).

## Test plan

- [x] Healthy run against prod still renders the status UI as before
- [x] Transport error (unreachable host) prints "Could not reach Kernel
API…"
- [x] `/status` 5xx + `/health` 5xx prints "Kernel API is down…"
- [x] `/status` 5xx + `/health` 200 prints "Kernel API is responding but
/status is unavailable…"

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> CLI-only error messaging and an extra HTTP probe on failure paths; no
auth, data, or API contract changes.
> 
> **Overview**
> **`kernel status`** now uses different error messages instead of one
generic “Could not reach Kernel API” for both network failures and bad
HTTP status from `/status`.
> 
> When `/status` returns a non-2xx, the CLI probes **`/health`** (3s
timeout). If `/health` is healthy, users see that the API is up but
**`/status`** is unavailable; otherwise they see that the API is down.
Transport errors on the initial `/status` request still report that the
API could not be reached.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
5622e69. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

Author: jarugupj

cmd/status.go

@@ -53,7 +53,15 @@ func runStatus(cmd *cobra.Command, args []string) error {
 	defer resp.Body.Close()
 
 	if resp.StatusCode < 200 || resp.StatusCode >= 300 {
-		pterm.Error.Println("Could not reach Kernel API. Check https://status.kernel.sh for updates.")
+		healthClient := &http.Client{Timeout: 3 * time.Second}
+		if healthResp, err := healthClient.Get(util.GetBaseURL() + "/health"); err == nil {
+			healthResp.Body.Close()
+			if healthResp.StatusCode >= 200 && healthResp.StatusCode < 300 {
+				pterm.Error.Println("Kernel API is responding but /status is unavailable. Check https://status.kernel.sh for updates.")
+				return nil
+			}
+		}
+		pterm.Error.Println("Kernel API is down. Check https://status.kernel.sh for updates.")
 		return nil
 	}