feat: PM-Agent also need to look at PR comments

From Gitea issue #116.

Authored by the PM agent's worker; the merge gate is the approver. Refs #116.

Agent: pm-agent (issue #116, mode revise)

platform/pm-agent/configmap.yaml

@@ -131,11 +131,16 @@ data:
 
   # --- mentions on a pull request (issue #116) --------------------------------
   # OFF. Turning it on makes the dispatcher also look at PULL REQUESTS: a mention of the bot
-  # account in a pull request's conversation, or inside an inline review thread, makes the PM
-  # read that pull request and reply in that same thread, and follow-up comments in a thread
-  # that already holds a mention continue the conversation with no new mention. It can ONLY
-  # reply — a mention cannot start, revise or push a branch; that is the second half of
-  # issue #116 and has its own issue.
+  # account in a pull request's conversation, in a review's body, or on a line inside an
+  # inline review thread, makes the PM read that pull request and reply where it was
+  # mentioned. It can ONLY reply — a mention cannot start, revise or push a branch; that is
+  # the second half of issue #116 and has its own issue.
+  #
+  # AN EXPLICIT MENTION IS THE ONLY TRIGGER, and a mention is self-limiting: one `@` gets one
+  # reply, and no other comment on the pull request is picked up. A comment that does not
+  # name the bot costs nothing — no reply and no model call — however recently the bot was
+  # mentioned or replied nearby. So the spend on this path is bounded by how often somebody
+  # types the handle, not by how busy the pull request is.
   #
   # WHY IT SHIPS OFF. Not one call on this path has been made against the live Gitea — the
   # branch that wrote it held no Gitea credential and no cluster — and the cheap mention
@@ -178,8 +183,8 @@ data:
   # Plan mode for the pull-request path: discover, assemble the payload, PRINT it to the
   # dispatcher's stdout, ask no model and post nothing. Setting it also enables the path, so
   # it is one knob to look before leaping. PM_DRY_RUN above implies it, because on this path
-  # the posted reply IS the action under test and also the marker that changes future
-  # behaviour — posting it would make a dry run not dry.
+  # the posted reply IS the action under test, and it also carries the idempotency marker —
+  # posting it would make a dry run not dry.
   PM_PLAN: "false"
 
   # If the gate refuses a worker's change, the branch is NOT pushed by default and the issue