A graph holding a flow.choose does not load back: LoadGraph refuses the subgraph for having no action_name #939

Epic: Serialization · Feature: — (the owner places it)

Found 2026-09-23, planning lane 14 of #916 (#931)

A graph that holds a flow.choose -- writ adopt's per-item guard, choose( file.exists(dest) → flow.failed | default: file.move → file.link ) -- serializes and runs, but does not load back:

op.LoadGraph: subgraph "flow.subgraph-65" has no action_name in the document

So any trace of such a graph cannot be read as a record: readback.Fold reports the graph unavailable and the run
folds as a finding. Deploy's graphs carry no subgraph, which is why the fold never met this before.

Mechanism

The graph document writes a flow.choose's branches as a subgraph, and the loader expects every unit to carry an
action_name; a subgraph unit carries none. Whether the writer should stamp one or the loader should accept a
subgraph without one is the codec's to decide.

The workaround in #931

writ adopt refuses an existing destination before the run, in RunBatches, and plans each item as file.move
then file.link with no guard subgraph; the graph then loads and the adoption is a deployment record. The in-graph
guard returns when this is fixed, if it is wanted.

Acceptance

• a graph holding a flow.choose round-trips through SaveGraph / LoadGraph with its checksum intact
• a test in pkg/op pins it