fork-genesis: break exportTriggerScript into separate controller-driven tasks

[bdchatham]

PR #179 lands the SND-driven fork-genesis sub-plan with the seid container's exportTriggerScript const doing all of: sidecar healthz wait, seid export, POST /v0/tasks upload-file submission, and poll-until-terminal — in one ~30-line bash blob.

Reviewer feedback on PR #179: this is a lot of orchestration baked into the container's bash. The controller already has the executor framework for task plans; the same operations could be modeled as separate controller-driven tasks instead of pod-internal bash:

• await-sidecar-healthy — controller polls the sidecar's healthz from outside the pod.
• submit-export — controller submits an export-state-shaped task to the sidecar.
• await-export-artifact — controller polls task completion + reads the resulting artifact path off the PVC.
• submit-upload-file — controller POSTs upload-file with the resolved path.
• await-upload-file — controller polls until terminal.

Trade-offs:

• Pro: failures attributable per-task (kubectl describe seinodedeployment shows which step failed); each step has its own retry/timeout knob; bash complexity in the seid container drops to zero.
• Pro: the controller's existing sidecar HTTP client (task.SidecarClient) replaces hand-rolled /dev/tcp HTTP/1.0 in bash.
• Con: more controller-side wire chatter (POST + multiple polls per step) vs. one Pod that orchestrates itself.
• Con: the seid container has to be reachable from the controller for the export step (it already is — same headless Service the bootstrap-stage sidecar uses).

Worth doing post-PR-#179 once the end-to-end flow runs once with the bash version and we observe what actually fails.

🤖 Generated with Claude Code

[bdchatham]

Closing as obsolete. The fork-genesis pipeline this decomposition was targeting has been reverted in #185. Research informing the decision (F1 bonded-pool, F2 sei-cosmos streaming exit-code) is preserved on seictl#145 for any future revisit.