Fix Linux install one-liner and first-rollout root cause noise - #580

Three fixes, one PR.

1. Install one-liner fails on Linux

The installer (~348 KB) is larger than Linux's 128 KB single-argument limit (MAX_ARG_STRLEN), so /bin/bash -c "$(curl -fsSL https://kwatch.dev/kwatch.sh)" fails with "Argument list too long". kwatch.sh reads its menu keys from stdin (read -rsn1, not /dev/tty), which rules out curl | bash. The new form is:

bash <(curl -fsSL https://kwatch.dev/kwatch.sh)

It works in bash and zsh on Linux and macOS, and the TTY stays interactive. Updated: README.md (2 places) and docs/release-notes/v1.0.0.md.

These kwatch.dev files still use the old one-liner and are not edited here:

• apps/web/src/pages/index.astro
• apps/web/src/pages/pro.astro
• apps/docs/docs/{installation, getting-started, kwatch-sh, cli-commands, license, upgrading, update, kwatch-manager, general-configuration}.md
• apps/docs/docs/guides/{pod-oomkilled, certificate-expiry-alerts, node-notready-alerts, crashloopbackoff-slack-alerts, pod-stuck-pending, imagepullbackoff}.md

2. Root cause blamed a first rollout instead of the crash log

In the rollout row, creation counts as a change. A brand-new payments-api that crashed with "FATAL: connection refused: postgres://db:5432" was therefore reported as "rolled out a change shortly before". The connection error class now rules out (vetoes) a Deployment, StatefulSet or DaemonSet whose only change in the window is its creation, including a delete followed by an immediate recreate. A real template change is still blamed as before. I didn't drop creation from the row altogether because that would weaken other scenarios (the scenario ratchet flagged config-run-as-non-root-rejected).

Tests are in internal/rootcause/explain/new_deployment_log_test.go: a new deployment, a recreated deployment, and a changed deployment (still blamed).

3. Noisy incident-detail lines for a recreated workload

Repro: kubectl delete deployment checkout-api, then create again, crashing with "dial tcp ... connection refused".

• "Also changed before it broke: checkout-api was deleted" and the "In the last 30 minutes" list no longer include the deletion of the affected workload's own earlier object when the same workload was created again afterwards.
• The "kwatch can't see ..." caveat is left out when the workload never worked (a never-healthy finding or its own creation) and a crash log line already says why (fatal, panic, or a connection error). Otherwise the caveat stays, including when the cause is unknown.

Tests are in internal/notification/compose/never_worked_test.go.

Not fixed, for follow-up: the caveat said "can't see nodes" even though the same alert said "Checked: node node01 is healthy". These are two different sources. The caveat comes from Source.Verifiable: the informer has not synced, or access was lost after a watch error. The "Checked" line comes from inventory relations. The chart RBAC does grant nodes, configmaps and serviceaccounts, so this looks like a transient sync or access-lost state on Killercoda. I couldn't reproduce it without a cluster, so it isn't changed here.

Checks

• make verify passes locally.
• CI still needs to confirm make ci (licensetest, actionlint, ShellCheck) and the e2e run.