Make task_comment mode explicit

[k2v7n24cbf-cyber]

Make task_comment mode explicit and hide legacy kind

Summary

• Adds explicit task-comment discipline to the built-in Tasks system guidance.
• Replaces the model-facing kind parameter with mode: "comment" | "result".
• Defaults omitted mode to ordinary comments.
• Keeps legacy kind: "result" accepted in the handler for older/direct callers,
  but stops advertising it to agents.
• Updates stale task guidance in the missing-result warning and onboarding
  template from kind: "result" to mode: "result".
• Adds regression coverage for mode to stored kind mapping and updates the
  server e2e task-comment fixture to use the new model-facing contract.

Reason / RCA

Agents were overusing kind: "result" for progress updates even when shared
context told them ordinary progress comments should omit kind.

Observed Behavior

In a live OpenAcme deployment running agents on gpt-5.5, this pattern was
seen across nearly all deployed agents: ordinary coordination progress was
posted as comments rendered under the Result label.

• One representative comment stated it was routing a coordination question and
  filing a child task, but it was posted as a result.
• Follow-up correction: explicitly said the previous progress comment was
  accidentally posted with result-kind, but that correction was also posted as a
  result.

This showed that prompt/context discipline alone was insufficient. The agent
understood the distinction in prose, but the exposed tool schema still pushed it
toward the only explicit enum value: kind: "result".

The first mitigation only strengthened the prose. Live behavior showed that was
not enough: an agent still posted ordinary progress as a Result, then posted a
second Result saying the first one was accidental.

The root cause is therefore the model-facing contract, not only the prompt text:

• task_comment is not an external MCP tool. It is an always-on OpenAcme system
  tool, merged into every agent's effective tool set.
• The schema exposes an optional kind field with exactly one visible value:
  "result".
• Ordinary comments are represented by the absence of kind, which is less
  salient to the model than selecting the only enum value shown in the schema.
• Even with stronger discipline text, the tool schema still made "result" look
  like the only explicit comment mode.
• A later scan found additional model-facing guidance in the missing-result
  warning and onboarding task template that still taught kind: "result".

This made agents treat kind as a general "comment type" field and reach for
"result" whenever a comment felt important, even if it was only a progress
update. The fix gives agents two explicit modes and makes the safe ordinary path
the default.

Code Observations

• packages/tools/src/system.ts lists task_comment and task_comments in
  SYSTEM_TOOLS, so every agent sees the task tools regardless of configurable
  MCP/tool settings.
• AgentManager.createAgentFromDef merges configured tools, MCP tools, and
  SYSTEM_TOOLS.
• ToolRegistry.getVercelTools() passes each tool's Zod schema and description
  into the model-facing tool block.
• task_comment previously stored ordinary comments as kind: null via
  kind: a.kind ?? null.
• The DB schema already models plain comments as nullable kind; reserved named
  kinds are "result" and "system".
• latestResult() reads the most recent kind: "result" comment. This PR does
  not add a duplicate-result restriction, preserving the current correction /
  follow-up behavior.
• task_update can emit a missing-result warning; that warning is also
  model-visible because agents receive tool results.
• packages/agent-catalog/templates/acme/resources/onboarding-task.md is seed
  guidance for new agents, so it must use the same mode terminology.
• packages/server/test/e2e/tasks.e2e.ts mocked the previous advertised
  kind: "result" shape; it now covers the new mode: "result" interface
  expected from agents.

Implementation Notes

This deliberately keeps one tool:

task_comment({ "id": 123, "body": "Progress: validating extraction.", "mode": "comment" })

or omit mode for ordinary comments:

task_comment({ "id": 123, "body": "Progress: validating extraction." })

Use result mode only for the assignee's final canonical answer before marking
the task done:

task_comment({ "id": 123, "body": "Final answer: ...", "mode": "result" })

No storage schema, permission rule, or comment read behavior changes. Stored
ordinary comments remain kind: null; result comments remain kind: "result".
Legacy direct callers passing kind: "result" still work.

Validation

• pnpm --filter @openacme/tools test -- tasks.test.ts
  • 31 tests passed.
• pnpm --filter @openacme/tools build && pnpm --filter @openacme/agent-core build
  • Package builds passed locally.
• pnpm --filter @openacme/agent-catalog build
  • Package build passed locally.
• pnpm --filter @openacme/server test:e2e -- tasks.e2e.ts
  • Server e2e suite passed locally. The package script ran 13 e2e files / 26
    tests.
• Live schema probe after patch:
  • model-facing task_comment keys: id, body, mode
  • kind is not present in the advertised schema
• Live behavior probe after patch:
  • omitted mode stores kind: null
  • mode: "comment" stores kind: null
  • mode: "result" stores kind: "result"
  • legacy kind: "result" still stores kind: "result"