automation: step error objects can surface as "[object Object]" in run-history consumers (split from #3425)

[os-zhuang]

背景（从 #3425 拆出）

#3425 的「Related」小节报告:16.1.0 上一个实际失败的 create_record 节点(crm_contact is required),其错误对象在某条展示路径上被字符串化成 "[object Object]",不可读。这与 readonly 剥离无关,是独立的错误序列化 bug,按分诊拆成本单。

main 现状核实(截至 2026-07-24)

服务端的抛错/返回路径已基本 .message 化,单看这些点位已不能复现:

• crud-nodes.ts 四个 CRUD 节点全部返回 `...failed: ${(err as Error).message}`;
• service-automation/engine.ts 的兜底是 err instanceof Error ? err.message : String(err);
• NodeExecutionResult.error 类型已收紧为 string;
• objectql ValidationError extends Error,message 是人类可读的 join(含 "X is required")。

剩余主要嫌疑:StepLogEntry.error 是结构化对象 { code, message }(见 service-automation/engine.ts 的 executeNode,NO_EXECUTOR / EXECUTION_ERROR / NODE_FAILURE 三处)。任何消费方把它整体当字符串渲染(模板字符串插值 / String() / React 直接输出)都会得到 [object Object]。嫌疑消费方:

1. objectui Runs 面板的 step error 渲染(跨仓,objectstack-ai/objectui);
2. CLI / rest-server 侧把 run history 摊平输出的路径;
3. 16.1.0 的旧代码路径(可能已在 16.x 后续重构中消失——需先在 main 复现再定位)。

建议动作

1. 先复现:main 上跑一个必然失败的 create_record(缺 required 字段),沿 run history → REST → Studio Runs 面板全链路看 error 的最终呈现;
2. 修掉消费方:凡渲染 step.error 的地方必须走 .message(保留 .code 作机器可读);
3. 回归测试:step error 为结构化对象时,渲染/序列化输出必须包含 message 文本、不得出现 [object Object](测试先验红)。

验收

• 失败节点在 Studio Runs 面板与任何日志/CLI 输出中都显示可读的 message;
• 全链路(engine 记录 → 持久化 → REST → UI)无 [object Object]。

Refs #3425 · #2948(原始观察上下文)