Align Plan-mode prompts on report_progress as the canonical plan tool (#786)

* fix: align Plan-mode prompts on report_progress as the canonical plan tool

Fixes #673.

Three sites disagreed on where Plan output should be posted, letting a
model synthesize a broken third interpretation (initial post via
`report_progress({ target_plan_comment: true })`, which then misses the
`existingPlanCommentId` precondition). This PR aligns all three on
`report_progress` as canonical, with `target_plan_comment` reserved for
revisions only:

- `action/modes.ts` Plan step 4 — spell out that the initial plan post
  uses `report_progress` WITHOUT `target_plan_comment`, and that
  revisions go through `select_mode`'s PlanEdit override.
- `action/mcp/comment.ts` `target_plan_comment` flag description —
  make the "revisions only" precondition explicit and call out the
  initial-post path by name.
- `action/utils/instructions.ts` Progress reporting paragraph — drop
  the misleading "(e.g., Plan comments)" parenthetical that read as
  "use create_issue_comment for plans".

`PlanEdit` (in `action/mcp/selectMode.ts`) was already correct and is
unchanged.

Intentionally out of scope (to keep the fix minimal): a `publish_plan`
tool, removing the vestigial `create_issue_comment({ type: "Plan" })`
branch, hardening the run-end cleanup guard for the
`target_plan_comment but no existingPlanCommentId` fallthrough, and
renaming `target_plan_comment`.

* align create_issue_comment description with report_progress as canonical plan tool

modes.ts

@@ -495,7 +495,7 @@ ${PR_SUMMARY_FORMAT}`,
 
 3. Produce a structured, actionable plan with clear milestones.
 
-4. Call \`${t("report_progress")}\` with the plan.`,
+4. Call \`${t("report_progress")}\` with the plan body. Do NOT set \`target_plan_comment\` — that flag is exclusively for revising an existing plan, and \`${t("select_mode")}\` will route you to a separate PlanEdit checklist when a prior plan comment exists for this issue.`,
     },
     {
       name: "Fix",