ci(dispatch): retry the sesh install on transient release-fetch failures

[mike-diff]

Closes #none (CI reliability fix, no issue).

Problem

The dispatch workflow intermittently fails at the install-sesh step with curl: (22) ... 404 on releases/latest/download/sesh-linux-amd64. Root cause is a race with release.yml: that workflow deletes and recreates the rolling release on every push to main, and for the few seconds the rebuild takes the asset URL 404s. A dispatch run whose install step lands in that window dies on a transient 404. Observed in run 28070847550: install 404 at 02:25:03, release republished at 02:25:05 (2s later).

Changes

• .github/workflows/dispatch.yml: the Install sesh step now runs install.sh in a retry loop (5 attempts, 10s apart) only for transient fetch failures: curl exit 22 (HTTP error, e.g. 404) and 18 (partial transfer). A checksum mismatch or any other failure is non-transient and aborts immediately with no retry.

install.sh itself is untouched: it is the public installer and its conservative no-retry curl flags are correct for one-shot user installs. The race tolerance belongs in the dispatch workflow, where concurrent workflows against the same rolling release actually happen.

How to test

• Simulated the retry control flow against five exit-code sequences: 404-then-success recovers; checksum mismatch (rc=1) aborts on attempt 1; persistent 404 exhausts 5 attempts then fails; happy-path first-try success does not retry; two 404s then success recovers on attempt 3. The safety property (never retry a checksum mismatch) holds.
• Next real dispatch that races a release rebuild will recover instead of failing.

Verification

go build ./... && go vet ./... pass (no Go touched). YAML valid, 12 steps. Retry logic simulated across 5 cases. No em dashes per AGENTS.md.