watch: fire on new comments, not just new tasks

A follow-up question on a task produced no event at all, so an unattended
conversation stalled silently. --comments polls the account's assigned tasks
(including done ones, where follow-ups land) and fires for comments written by
anyone else.

Guards: comments by the account itself never fire, so a replying agent cannot
wake itself; on first sight of a task the newest comment id is adopted without
firing, so enabling this does not replay history; the comment id is recorded
before the command runs, so a wedged harness is not relaunched every poll.

README.md

@@ -109,6 +109,26 @@ Available in the command: `{task_id}` `{title}` `{project_id}` `{priority}`
 `{labels}` `{url}`. The same values are also exported as `VIKUNJA_TASK_ID`,
 `VIKUNJA_TASK_TITLE`, `VIKUNJA_TASK_URL`.
 
+### Replying to comments
+
+Add `--comments` and the watcher also fires when **someone else** comments on one
+of your tasks:
+
+```sh
+vk watch --comments --interval 30 -- nullclaw --task {task_id}
+```
+
+- Scans your assigned tasks **including done ones** — a follow-up question almost
+  always lands on a task that was just closed.
+- Your own comments never fire it, so an agent replying cannot wake itself.
+- On first sight of a task the newest comment id is adopted **without firing**, so
+  turning this on does not replay the whole history. The flip side: a comment
+  already sitting there when you enable it will not fire either. To pick it up,
+  delete that task's entry from the `comments` map in the state file.
+- The command gets `VIKUNJA_TRIGGER=comment` plus `VIKUNJA_COMMENT`,
+  `VIKUNJA_COMMENT_AUTHOR`, `VIKUNJA_COMMENT_ID` alongside the usual task vars.
+  Task triggers set `VIKUNJA_TRIGGER=task`.
+
 ### Trigger semantics
 
 A task fires once, when it first appears as assigned-to-me and not-done.