Follow up: preserve tool-failure provenance after #1452 python trigger fix

[ericksoa]

Context

#3931 fixed and merged the narrow sandbox-side trigger from #1452: the base image now provides /usr/local/bin/python -> /usr/bin/python3, so bare python invocations should no longer fail with python: command not found. That PR merged as d4d4a40 and auto-closed #1452 via Fixes #1452.

This issue keeps the broader runtime trust/provenance concern open. The remaining problem is not Python availability; it is how OpenClaw/NemoClaw handles failed tool or child-agent results before producing user-facing assistant output.

Remaining Problem

When a tool call or sub-agent result fails or is untrusted, the assistant should not present fabricated success, fake file paths, fake command output, or unverified child-sourced data as confirmed work. Users need visible provenance that distinguishes real execution results from failed, missing, or unverified work.

Acceptance Criteria

• Reproduce a failure path independent of the bare python command, or document why current runtime behavior has changed.
• Ensure failed tool/sub-agent execution is visible in the assistant/user-facing transcript with enough detail to distinguish real outputs from incomplete or unverified work.
• Add regression coverage for at least one failure path that does not depend on the python command being absent.
• Keep fix(sandbox): add python -> python3 symlink in base image (#1452) #3931 as the sandbox-side trigger fix; use this issue for the broader runtime trust/provenance behavior.

References

• [Bug] Agent fabricates successful execution output after tool failure (exec: python not found) #1452: original report and umbrella issue, now closed by the sandbox-side trigger fix.
• fix(sandbox): add python -> python3 symlink in base image (#1452) #3931: merged fix for bare python availability in the sandbox base image.
• fix(sandbox): add python -> python3 symlink in base image #1455: earlier PR carrying the same sandbox-side symlink concept.