Report current and historical workflow progress as separate counters

Problem

A single progress percentage can combine incompatible measurements:

• current successful nodes;
• current terminal nodes, including failures;
• historical terminal occurrences;
• a graph whose total changes after dynamic expansion;
• nodes that a retry operation reopened.

The displayed percentage can decrease even when durable attempt history is intact. Operators cannot determine whether the workflow lost state, expanded the graph, changed the numerator, or intentionally reopened work.

Proposed enhancement

Report these current-state counters separately in human and JSON output:

• finished
• failed
• active
• pending
• total
• reopened

Also report:

• the current activation or workflow generation;
• explicit changes to the total node count;
• cumulative historical attempt counts in a separate section;
• the reason and closure size when a retry reopens nodes.

Do not use one percentage for both current state and cumulative history.

Acceptance criteria

• Human-readable status output shows the current counters together.
• JSON output exposes stable typed fields for the same counters.
• Dynamic graph expansion is an explicit event or diagnostic.
• Retry output reports the number of reopened producers and dependents.
• Historical terminal occurrences cannot be mistaken for current completion.
• Tests cover graph expansion, failed nodes, retry reopening, and resumed activations.

Start by locating the human-readable status output, its JSON representation, and the workflow progress and retry reporting paths. Trace how current counters, historical attempts, graph expansion, and resumed activations are currently represented. Done means both output formats expose the requested separate fields and tests cover graph expansion, failed nodes, retry reopening, and resumed activations.