resume --refresh-controller retries failed nodes with stale rendered prompts

Summary

resume --refresh-controller can adopt new controller/runtime code while unfinished or explicitly retried agent tasks continue using the prompt bytes materialized by an earlier controller generation. Prompt fixes therefore do not reach the nodes that need them, even though the operator explicitly selected the refreshed controller to continue the run.

This makes prompt-only or prompt-contract fixes ineffective for campaign recovery: the code is refreshed, the failed producer is replayed, but the model receives the same stale instructions.

Production evidence

A stopped default-profile campaign underwent multiple authenticated controller refreshes and then retried failed producer/verifier closures. The selected controller contained the central JSON-validator renderer and the task metadata contained pinned schema filenames and digests. Nevertheless, retried failed producers still received their original prompt.rendered.md files, which omitted all concrete validation commands.

A dynamic class producer retried under a later controller received the same full prompt contract as its first generation: it still said to run commands "shown above", while its Output Contract contained no Validate against, Validation command, or Contract validation command fields.

Expected behavior

When --refresh-controller is selected, unfinished/newly reset producer tasks should use prompts rematerialized by that selected controller from the current sealed task/topology authority. Durable completed task outputs must remain untouched and must not be replayed merely because their historical prompt differs.

Acceptance criteria

• resume --refresh-controller rematerializes prompts for unfinished, failed, or explicitly reset producer attempts using the selected controller generation.
• Completed producer tasks retain their historical output and are not replayed solely due to prompt digest changes.
• The selected prompt/controller generation and prompt digest are recorded for every newly executed attempt.
• The engine does not silently prefer an old inline inputTask.prompt or stale prompt.rendered.md over the refreshed controller's rematerialized prompt.
• Runtime-materialized dynamic tasks are regenerated from their authenticated dynamic item plus the refreshed template, without promoting runtime-only prompt paths into the immutable base task set (preserve the #763 boundary).
• A regression starts a run with prompt v1, stops after one completed and one failed producer, refreshes to prompt v2, and proves only the failed producer executes with v2.
• An explicit non-refresh resume retains the original prompt semantics.

Relationship to existing work

#939 proposes restoring native Smithers continuation when controller code changes. This issue is narrower: it defines which prompt bytes unfinished/retried model work must receive when the operator explicitly requests a refreshed controller. It does not require replaying completed work.

Start at the resume --refresh-controller entry point and trace prompt materialization, including precedence between inputTask.prompt, prompt.rendered.md, and the selected controller generation. Add the described v1/v2 regression around one completed and one failed producer, then verify only unfinished work receives v2 while non-refresh resume retains the original semantics.