Modal retry ownership can arrive after the command failure check

The Modal retry command can return before its asynchronously started workflow reports ownership, making an immediate event-stream fingerprint racy.

Minimal generic reproduction:

1. Use a retained external Solidity workspace with one exhausted selected task.
2. Make retry-task reset that task, start the workflow asynchronously, return RETRY_TASK_FAILED before reporting ownership, and exit nonzero.
3. Shortly after process exit, append RunStarted, terminal frame records, and RunFailed whose cause is the exact selected linked-worktree git read-tree --reset -u <tree> / index.lock collision. Do not append NodeStarted.
4. Compare the retained event stream immediately around the command process.

Observed diagnostics:

attempts=1
byte_stable_streams=1
output_ownership_free=1
read_tree_signatures=0
lock_path_signatures=0

The immediate check reports a byte-stable, apparently unowned command. The same stream then receives a complete terminal collision suffix after the worker has already failed closed.

Expected: recovery uses a bounded delayed-ownership window. It may retry only after validating that the append-only suffix belongs to the same inner run, contains no NodeStarted, ends in RunFailed, and carries the exact selected-worktree collision. Any other append, timeout, identity change, or nonterminal state remains terminal.

Start at the retry-task command and the retained append-only event stream described in the reproduction. Trace how the immediate failure check determines ownership and compare the later stream suffix against the same inner run. Done means only the exact terminal selected-worktree collision with no NodeStarted can trigger a bounded retry; other appends, identity changes, timeouts, or nonterminal states remain terminal.