#4236 Failed remote methods lose named command-result output handles at Serve

At pinned revision e459d219fe4c9b37c4fdd3f4a7611bf1b6880226, a remote method can write a command-result output and then throw on a nonzero exit. The worker returns those handles in its error reply, but Serve does not return them through the normal failed-step output path.

Source trace:

• src/worker/exec_dispatch.ts:319–334: the catch block returns status:error and outputs:toOutputs(getHandles()).
• src/serve/dispatch_service.ts:1102–1127: the result.status === error branch settles the failed lease, then throws Error/UserError without returning result.outputs.
• src/serve/dispatch_service.ts:1137–1143: only the success branch returns result.outputs.
• src/serve/dispatch_service.ts:1144–1167 attaches written datastore versions with withWrittenVersions; that is distinct from exposing the worker’s named output handles. This report does not claim all persisted artifact bytes disappear.

Observed: a client’s failed remote workflow step reported only “Command exited with code 1”; the normal output inventory contained method-summary reports, without the command stdout/stderr result. A bounded artifact read did not complete, so this report makes no claim about unreadable artifact contents.

Expected: a failed remote method’s already-written, redacted command-result handles remain available through failed-step output/history readers while both step and run stay FAILED. Preserve existing redaction and failure semantics.

Suggested regression: execute a remote test method which writes a declared public diagnostic result, then throws. Verify the worker error reply contains the handle, the run stays FAILED, normal failed-step readers expose that same diagnostic handle, and a secret sentinel is redacted. Compare equivalent local execution.

Current client workaround: preserve output with ignoreExitCode:true, then fail the workflow with a native assertion on the recorded exitCode. A fix should make diagnostics available without requiring this graph change.

A separate worker-disconnect case can legitimately have no recorded stdout/stderr and an unknown exitCode. Missing diagnostics must stay distinguishable from empty stderr or a confirmed command exit.