[Refactor] 统一代码执行公共契约与输出限制实现，解除 Docker 对节点 Starter 的依赖 #42

问题与证据

当前 code-executors/argi-code-executor-docker/pom.xml 依赖 Core 的 argi-starter-builtin-nodes，只为使用其中 CodeExecutor、执行配置/结果等契约。DockerCodeExecutor 因而被绑定到图节点实现库，独立 Agent/Workflow 无法自然复用。

Core graph/node/code/ExecutionOutputBuffer.java 与 Extensions graph/node/code/docker/ExecutionOutputBuffer.java 经源码比较，除 package 声明外完全一致。输出大小限制和截断行为存在两份维护源，后续修复容易漂移。

建议方案

• 为本地、Docker 以及未来其他执行后端建立唯一的中立执行契约与输出限制实现；Loop 的 CodeExecutorNodeAction 只承担适配。
• 优先评估归入现有合适的能力模块；只有依赖隔离和独立消费者确实需要时才新增小模块，不为了去重继续制造一批 API/impl/common/starter 空壳。
• Docker SDK 与后端生命周期继续留在独立 Docker 实现，不能为减少模块而与本地执行器、通用节点库打包。
• 沙箱的工具集合、文件系统与会话生命周期不等同于进程执行，不要求直接合并整个 argi-sandbox；只在语义一致处复用公共执行能力。

收益与替代方案

移除 Docker → 节点 Starter 的反向依赖，允许独立 Agent/Workflow 使用代码执行，并统一输出限制维护。仅把重复类变成节点库 public 工具虽改动小，但会继续固化依赖方向，不应作为最终方案。

兼容与验收

• 明确请求、结果、错误、超时、取消、输出字节上限及截断语义，不能通过合并改变执行权限默认值。
• 本地进程与 Docker 的资源清理、超时后终止行为分别保留实现与测试；共享契约不能虚报各后端能力。
• 建立共同的边界测试：多字节输出、跨 stdout/stderr 的总量限制、超长单块、截断标志、超时/取消和失败清理。
• 提供现有 CodeExecutor 实现者、包名和坐标的迁移说明；节点历史定义兼容与 Core 关联 issue 协调。
• 最终 Docker 依赖树不含 builtin-nodes/Loop/Agent 执行引擎，公共能力不含 Docker 或 Boot SDK。

关联：#30、#21，以及 Core agentic-ai-java/argi#197、agentic-ai-java/argi#198。

节点库职责与坐标迁移任务：agentic-ai-java/argi#225。