Decide whether a retry-rescued run should report a green run conclusion

[joshua-temple]

Problem

When a deploy fails and a retry shim rescues it (the deploy ultimately succeeds), the orchestrate run's aggregate conclusion is still failure. cascade intentionally never emits continue-on-error on reusable-workflow caller jobs, so a failed base deploy job reds the run even when a later retry succeeds. The effective (success) result is correctly propagated to the state write and to dependent deploys, but the run badge stays red.

Consequence

Anything keying on the run conclusion (branch protection, external gates, or a human reading the Actions UI) sees a rescued deploy as failed, which can surprise users for a feature whose purpose is resilience.

Decision to make

• Keep the current contract: rescue is proven via job-result expressions and the state write; the run conclusion is red by design (no continue-on-error).
• Or make a retry-rescued run report a green conclusion, which means reversing the no-continue-on-error contract for retried deploys and accepting the broader failure-semantics implications.

Context

Retry-rescue mechanics are validated on the live fleet (base fails, retry succeeds, dependent runs, state advances); only the run-conclusion semantics are open. Exercised by cascade-example-retries. Related: #645.