docs(cli): clarify issue rerun semantics

The CLI table described `multica issue rerun <id>` as "Rerun the most
recent agent task", which led users to expect it would re-run whichever
agent ran last. The actual behavior is to enqueue a fresh task for the
issue's **current** agent assignee, regardless of who ran most
recently — see `TaskService.RerunIssue` in
`server/internal/service/task.go`.

Also fix a stale claim in `tasks.mdx`: the "Manual rerun" section
described session inheritance as "Yes", but commit b1345685 made manual
rerun pass `force_fresh_session=true` precisely to avoid replaying a
poisoned session. Only **automatic retry** still inherits the session.

Updates EN + ZH mirrors of `cli.mdx` and `tasks.mdx`.

Co-authored-by: multica-agent <github@multica.ai>

apps/docs/content/docs/cli.mdx

@@ -54,7 +54,7 @@ For the difference between token types, see [Authentication and tokens](/auth-to
 | `multica issue status <id> --set <status>` | Shortcut to change status |
 | `multica issue search <query>` | Keyword search |
 | `multica issue runs <id>` | Show agent runs on an issue |
-| `multica issue rerun <id>` | Rerun the most recent agent task |
+| `multica issue rerun <id>` | Re-enqueue a fresh task for the issue's current agent assignee |
 | `multica issue comment <id> ...` | Nested: view / post comments |
 | `multica issue subscriber <id> ...` | Nested: subscribe / unsubscribe |
 | `multica project list/get/create/update/delete/status` | Project CRUD |

apps/docs/content/docs/cli.zh.mdx

@@ -54,7 +54,7 @@ Token 类型的详细区分见 [认证与令牌](/auth-tokens)。
 | `multica issue status <id> --set <status>` | 快捷改状态 |
 | `multica issue search <query>` | 关键字搜索 |
 | `multica issue runs <id>` | 查看 issue 上智能体跑过的任务 |
-| `multica issue rerun <id>` | 重跑最近一次智能体任务 |
+| `multica issue rerun <id>` | 给该 issue 当前的智能体分配人重新创建一条任务 |
 | `multica issue comment <id> ...` | 嵌套：看 / 发评论 |
 | `multica issue subscriber <id> ...` | 嵌套：订阅 / 取消订阅 |
 | `multica project list/get/create/update/delete/status` | Project CRUD |

apps/docs/content/docs/tasks.mdx

@@ -77,9 +77,10 @@ multica issue rerun <issue-id>
 
 Behavior:
 
-- **Cancels** the currently running task (if any)
-- Creates a **brand-new** task — attempt count resets to 1, even if the original task hit the attempt ceiling
-- Inherits the previous session ID; if the corresponding AI coding tool supports session resumption, the new task continues from the previous context
+- Targets the issue's **current agent assignee** — not whoever ran the most recent task. If the assignee changed since the last run, rerun follows the current assignment. To rerun a specific agent that is no longer the assignee, reassign the issue first, then rerun.
+- **Cancels** the assignee's queued or running task on this issue (if any). Tasks owned by other agents on the same issue (e.g. parallel @-mention runs) are left alone.
+- Creates a **brand-new** task — attempt count resets to 1, even if the original task hit the attempt ceiling.
+- Starts a **fresh agent session** — the prior session ID is **not** inherited. A manual rerun means you've judged the previous output bad, so resuming the same conversation would replay the same poisoned state. (Automatic retry, by contrast, does inherit the session — that path is for infrastructure failures, not bad output.)
 
 Comparison:
 
@@ -88,7 +89,8 @@ Comparison:
 | Trigger | System, based on failure reason | You, manually |
 | Ceiling | 2 attempts | No limit |
 | Applicable sources | Issues, chat | All sources |
-| Session inheritance | Yes | Yes |
+| Agent picked | Same agent as the failed task | Issue's current assignee |
+| Session inheritance | Yes (resumes prior session) | No (fresh session) |
 
 ## How a failed task affects issue status
 
@@ -98,7 +100,7 @@ If an issue-triggered task fails (and no automatic retry succeeds) because the i
 
 Yes — as long as the AI coding tool supports session resumption.
 
-Multica pins the session ID **twice** during a task: once at the start (when the AI tool returns its first system message), and once at the end (on completion or failure). The first lets the daemon recover if it crashes mid-run; the second is reserved for future reruns. On the next rerun or automatic retry, that ID is passed back so the agent can pick up the previous conversation and file state.
+Multica pins the session ID **twice** during a task: once at the start (when the AI tool returns its first system message), and once at the end (on completion or failure). The first lets the daemon recover if it crashes mid-run; the second is reserved for the next **automatic retry**, where that ID is passed back so the agent can pick up the previous conversation and file state. **Manual rerun deliberately skips this** and starts a fresh session — see [Manual rerun vs. automatic retry](#manual-rerun-vs-automatic-retry).
 
 But **which AI coding tools actually support this** varies a lot:
 

apps/docs/content/docs/tasks.zh.mdx

@@ -77,9 +77,10 @@ multica issue rerun <issue-id>
 
 行为：
 
-- **取消**当前正在跑的任务（如果有）
-- 创建一个**全新**的执行任务——尝试次数重置为 1，即使原任务已达最大尝试
-- 继承上一次的会话 ID；如果对应的 AI 编程工具支持会话恢复，会接着上次的上下文继续
+- 跑的是 issue **当前的智能体分配人**——不是上一次跑过的 agent。如果分配人在上次运行后改了，rerun 会跟着新的分配人走。要重跑一个已经不再是分配人的智能体，先把 issue 改派回它，再 rerun。
+- **取消**该分配人在这条 issue 上 queued / running 的任务（如果有）。同 issue 上其它 agent 的任务（例如 @-mention 触发的并行任务）不会被一起取消。
+- 创建一个**全新**的执行任务——尝试次数重置为 1，即使原任务已达最大尝试。
+- 启动**全新的智能体会话**——**不**继承之前的会话 ID。手动重跑意味着你已经判定上一次的产出不行，再继续之前的对话只会重放被污染的上下文。（自动重试则相反，会继承会话——那条路径处理的是基础设施层面的失败，不是产出不好。）
 
 对比：
 
@@ -88,7 +89,8 @@ multica issue rerun <issue-id>
 | 触发 | 系统基于失败原因自动执行 | 你主动发起 |
 | 上限 | 2 次 | 无上限 |
 | 适用来源 | issue、聊天 | 所有来源 |
-| 会话继承 | 是 | 是 |
+| 跑哪个 agent | 失败任务原本的 agent | issue 当前的分配人 |
+| 会话继承 | 是（接着上次会话） | 否（全新会话） |
 
 ## 失败的任务对 issue 状态有什么影响
 
@@ -98,7 +100,7 @@ multica issue rerun <issue-id>
 
 可以——前提是对应的 AI 编程工具支持会话恢复。
 
-Multica 在任务过程中**两次**保存会话 ID——任务一开始（AI 工具返回第一条系统消息时）pin 一次，任务结束（完成或失败）时再 pin 一次。前者让守护进程中途崩溃时也能恢复，后者给之后的重跑用。下次重跑或自动重试时把这个 ID 传回去，智能体就能接着上次的对话、文件状态继续。
+Multica 在任务过程中**两次**保存会话 ID——任务一开始（AI 工具返回第一条系统消息时）pin 一次，任务结束（完成或失败）时再 pin 一次。前者让守护进程中途崩溃时也能恢复，后者留给下一次**自动重试**——届时把这个 ID 传回去，智能体就能接着上次的对话和文件状态继续。**手动重跑会主动跳过这一步**，永远从全新会话开始——见 [手动重跑和自动重试的区别](#手动重跑和自动重试的区别)。
 
 但**哪些 AI 编程工具真的支持**差别很大：