docs(workflow): correct --name recovery semantics; document target eligibility

[bdchatham]

What

Two fixes to workflow/README.md, both verified against sei-k8s-controller main @ 2d670ad and this repo @ 821f2f8 (v0.0.70).

1. --name is not a recovery for a Failed workflow

Re-Run Semantics offered, for either terminal phase: "pass --name to run under a fresh workflow name instead." That holds for a Complete run, whose hold was already released — but not for a Failed one.

Removing the workflow is what releases the node, and adoption is exclusive: reconcileWorkflow dispatches to driveAdoptedWorkflow whenever status.adoptedWorkflow is non-nil, so maybeAdoptWorkflow never runs while a Failed workflow is parked. The fresh --name workflow is therefore never adopted — it compiles no plan, makes no progress, and the watch ends at --timeout with the node still held.

Worth stating plainly since the CLI's own preflightPhaseError carries the same suggestion on its Failed branch, and the pre-flight is name-scoped so a --name run skips it entirely.

2. The force annotation is currently mandatory, not break-glass

verifyWorkflowDataSafe fails closed until the sidecar exposes the data-state query, so an un-annotated delete parks the workflow Terminating with the node still held and a WorkflowDeleteHeld warning event. Now documented, along with the fact that annotating a workflow already stuck Terminating releases it on the next poll — order isn't load-bearing.

Also: a new Eligible Targets section

The adoption-time refusals weren't documented anywhere. A SeiNode is exactly one mode (CRD CEL), only fullNode is eligible, and because the workflow's own CEL can't see the target's mode the refusal lands at adoption — failing the workflow terminally so kubectl wait --for=condition=Failed resolves. Also covers one-workflow-per-node and the paused / mid-drift-plan deferrals.

Not changed

Two claims I could not verify from this repo or the controller, both pre-existing: --backend rocksdb requiring a seid image built with -tags rocksdbBackend, and seid refusing to start when the new store layout is empty while the split is enabled. Both are sei-chain behavior.

Test

Docs-only. go test ./workflow/... green; make lint is gofmt-only. Nothing in the Go tree references the README.

🤖 Generated with Claude Code

[cursor]

PR Summary

Low Risk
Documentation-only; no runtime or CLI behavior changes.

Overview
Docs-only updates to workflow/README.md for seictl workflow state-sync.

Adds Eligible Targets: state-sync applies to fullNode only; other SeiNode modes are refused at adoption (terminal Failed), with notes on one workflow per node and deferral when the node is paused or mid-drift.

Re-Run Semantics is rewritten to separate Complete vs Failed recovery. A fresh --name can follow a Complete run without deleting the old CR, but cannot fix a Failed run that still holds the node—you must force-delete (sei.io/force-delete-workflow) then delete first; the doc states that annotation is required today (un-annotated delete can leave the workflow Terminating with the node still held) and warns that --name alone leaves a new workflow unadopted until the failed one is removed.

^{Reviewed by Cursor Bugbot for commit 1e20fb1. Bugbot is set up for automated code reviews on this repo. Configure here.}