feat(sidecar): gov-software-upgrade handler (PR-C of #163)

[bdchatham]

Software-upgrade proposal handler. Single-purpose task type, mirroring gov-vote's shape — no Type discriminator, no dispatch switch. Future proposal types will be separate task types in separate files.

(Previously shipped as a meta-handler with a Type field; refactored after user pushback on the one-way-door risk and the audit-trail weakness of an extensible switch for non-idempotent broadcasts.)

Summary

• New `TaskGovSoftwareUpgrade` task type + `sidecar/tasks/gov_software_upgrade.go` handler that builds Cosmos gov v1beta1 `MsgSubmitProposal` wrapping a `SoftwareUpgradeProposal`.
• `GovSoftwareUpgradeTask` Go client SDK helper with matching server-side validation.
• `InitialDeposit` denom-whitelisted to `usei` (symmetric with `Fees`) — catches wrong-denom typos at the sidecar layer.

⚠️ Rehydration risk shipped knowingly

`MsgSubmitProposal` is NOT chain-idempotent. A crash between `BroadcastSync` and task-result persist re-runs this handler on restart and broadcasts a SECOND proposal with identical content. The operator pays `InitialDeposit` (~10 SEI) twice. For software-upgrade the chain-level execution damage is bounded (upgrade module applies once at the named height); the pattern MUST NOT be reused for non-MVP proposal types without first wiring the pre-broadcast txHash marker from #174.

Risk is documented at file-header scope. Each future proposal-type handler is a separate file deliberately — that file MUST evaluate its own rehydration impact before shipping. The diff shape itself is the audit signal: adding a new proposal type means a new file + a new test file + a new client task type + a new engine registration, not a one-line switch-case PR.

User-confirmed scope call (better than blocking the workstream on #174's hardening lift).

Why per-type handlers instead of one meta-handler

• Forced per-handler idempotency review. Each new proposal-type handler is a new file with a fresh REHYDRATION WARNING. A meta-handler with a Type discriminator would let `case "community-pool-spend":` slip in as a one-line PR with no structural review signal.
• Audit-trail clarity. The diff shape forces reviewer attention on the per-Msg analysis.
• Consistency with gov-vote. Single-purpose Handler/buildXxxMsg shape.

(Note: kube-rbac-proxy in #165 issues one coarse SAR — `create seinodetasks.sei.io` — independent of task body type, so per-handler files do NOT buy authz granularity at the proxy boundary today. The audit-trail argument is the real benefit.)

Follow-ups tracked in #176

• UpgradeHeight floor vs current chain height (post-feat(sidecar): authn + authz middleware on mutating endpoints #165)
• Title/Description length caps (post-feat(sidecar): authn + authz middleware on mutating endpoints #165)
• Engine run-value ctx plumbing
• Process-start banner enumerating Per-handler idempotency review + TaskResult.Output engine extension #174-risk handlers

Items 1 and 2 in #176 (nested wire-format shape, shared client/server validation) are moot after the refactor.

Test plan

• `TestBuildSoftwareUpgradeMsg` table — happy path (locks SDK `MsgSubmitProposal.ValidateBasic` and `SoftwareUpgradeProposal` content type) + 10 validation mutations (missing fields, deposit parse failures, zero/non-usei/mixed-denom rejection, nil keyring, missing key)
• `TestGovSoftwareUpgradeHandler_HappyPath` — end-to-end via fake txClient; locks `SoftwareUpgradeProposal` InterfaceRegistry registration (Any-packed content would fail at `txCfg.TxEncoder` if dropped)
• `go build ./...` clean
• `go test ./...` clean
• `go test -race ./sidecar/tasks/` clean
• `gofmt -s -l .` clean
• `golangci-lint run --new-from-rev=origin/main ./...` reports 0 issues
• Coral trio cross-review on the refactor — all clean from security lens; platform + k8s findings synthesized into final commit

🤖 Generated with Claude Code