feat: Wire agent system_prompt into guest runtime (Phase 1)

[TyreeZhao]

Summary

• Resolve AgentDefinition.system_prompt at run time on the Go host and pass it to the guest via --system-prompt-file, with a fallback retry for older guest runtimes that do not recognize the flag.
• Compose Agent Identity + the existing MPI catalog into a single systemContext in agent-compose-runtime-js, injected into Codex developer_instructions, Claude systemPrompt.append, and Gemini prompt text as an interim prepend until a native system channel exists.
• Propagate agent definition binding through loader runs and managed project runs, and add host/runtime tests plus EN + zh-CN design/runtime docs.

Motivation

system_prompt was already persisted, exposed in API/Proto, and editable in the Agents UI, but the execution path never read it. Only the MPI catalog reached provider system/developer instruction channels, so configured agent personas had no effect.

Test plan

Automated

• go test ./pkg/agentcompose -run 'SystemPrompt|AgentSystem' -count=1
• go test ./pkg/agentcompose -count=1
• npm test -- --run in runtime/javascript

Manual

• Manual: agent with system_prompt: "Reply only in Chinese" obeys after Codex/Claude chat run
• Manual: empty system_prompt skips system-prompts/ and agent runs normally (simplified regression; no OctoBus/capsets in local env)
• Manual: Codex session resume after prompt edit uses updated instructions
• Manual: loader bound to agent definition inherits system_prompt

Manual test notes

• Verified on local go run ./cmd/agent-compose daemon with data under ~/.local/share/agent-compose/.
• Empty system_prompt regression confirmed by filesystem check: state/agents/prompts/ present, system-prompts/ absent.
• Full MPI-only comparison was not exercised locally because OctoBus capability sets are unavailable in this environment.