[codex] Guard document comment wake boundaries (#7766)

## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The execution control plane uses issue comments, assignments,
monitors, blockers, and interactions to decide when agent-owned work
should wake and run.
> - Top-level issue comments are actionable issue-thread feedback for
the assignee, but document-scoped comments are review context unless
they are converted into an explicit routing primitive.
> - Document annotation comments were still wired into the same
`issue_commented` wake path as top-level issue comments.
> - That made document activity capable of waking an assignee and
looking like an execution path even when no issue-level handoff
happened.
> - This pull request narrows the wake boundary so document annotation
activity stays document-scoped while normal issue comments continue
waking the assignee.
> - The benefit is fewer spurious wakeups and clearer non-terminal issue
liveness semantics.

## Linked Issues or Issue Description

Internal Paperclip work: [PAP-10613](/PAP/issues/PAP-10613),
[PAP-10640](/PAP/issues/PAP-10640)

Problem description:

- Document annotation thread creation and annotation comments were
treated as assignee wake sources.
- Document-scoped activity should remain visible as document/review
context, but should not by itself act as a queued issue wake, monitor,
approval, interaction response, blocker, or terminal disposition.
- Top-level issue comments should still wake the assignee on
agent-assigned, non-terminal issues.

Related PR search performed:

- Found related prior document annotation work: #6733.
- Found related prior issue-comment wake work and revert context: #7678,
#7765.
- No existing PR for `PAP-10613-why-is-this-task-not-running`.

## What Changed

- Removed the document annotation comment assignee wake helper from
issue routes.
- Kept document annotation reference sync and activity logging intact.
- Documented the distinction between top-level issue comments and
document-scoped comments in `doc/execution-semantics.md`.
- Added route tests proving document/document annotation activity does
not wake the assignee.
- Added route coverage proving top-level board issue comments still wake
the assignee.

## Verification

- `pnpm exec vitest run
server/src/__tests__/document-annotation-routes.test.ts
server/src/__tests__/issue-update-comment-wakeup-routes.test.ts` — 2
files passed, 9 tests passed.
- `pnpm --filter @paperclipai/server typecheck` — passed.
- `git status -sb` — clean branch tracking
`origin/PAP-10613-why-is-this-task-not-running`.

## Risks

- Low to moderate behavior change: document annotation comments no
longer wake the issue assignee automatically.
- Operators who want document feedback to route work must use an
explicit primitive such as assignment, issue-thread comment, agent
mention, issue-thread interaction, approval, blocker, or delegated
follow-up.
- No database migration or public API shape change.

> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.

## Model Used

OpenAI Codex, GPT-5-based coding agent with shell/tool use enabled.
Exact hosted runtime model identifier beyond GPT-5 was not exposed in
this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] If this change affects the UI, I have included before/after
screenshots
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>

doc/execution-semantics.md

@@ -1,7 +1,7 @@
 # Execution Semantics
 
 Status: Current implementation guide
-Date: 2026-05-23
+Date: 2026-06-08
 Audience: Product and engineering
 
 This document explains how Paperclip interprets issue assignment, issue status, execution runs, wakeups, parent/sub-issue structure, and blocker relationships.
@@ -237,6 +237,23 @@ The valid action-path primitives are:
 - a first-class blocker chain whose unresolved leaf issues are themselves healthy
 - an open explicit recovery action that names the owner and action needed to restore liveness
 
+### Comment and document activity wake sources
+
+Issue-thread comments and document-scoped comments have different wake semantics.
+
+A top-level issue comment created by a board user or other user on an agent-assigned, non-terminal issue may wake that issue's assignee. This is the normal "the owner should see new issue-thread feedback" path, and the wake payload should identify the issue comment that caused the wake when possible.
+
+Issue document comments, document annotation comments, and document review comments do not wake the issue assignee by default. They remain visible as document activity and should be discoverable from the issue's document/review surfaces, but document activity is not itself an issue execution path. A document comment can provide evidence or context for the next run, but it must not be treated as a queued wake, monitor, approval, interaction response, blocker, or terminal disposition.
+
+Document-scoped activity may still route work when it is converted into an explicit action-path primitive. Valid routing exceptions include:
+
+- an issue mention or structured agent mention that intentionally wakes or assigns a named participant
+- a document-review assignment that names a reviewer or assignee for the review state
+- a response to an issue-thread interaction, such as `request_confirmation`, `ask_user_questions`, or `suggest_tasks`
+- intentional board routing that assigns or reassigns the issue, opens a first-class blocker, creates delegated follow-up work, or queues a typed wake
+
+Freeform document approval text is not auto-acceptance. Plan approval, implementation approval, or review acceptance must flow through the explicit interaction, approval, execution-policy, assignment, or blocker primitives that define who owns the next move.
+
 ### Adapter-backed workspace coherence
 
 For adapter-backed execution, an active run or queued wake counts as a live path only when Paperclip can also prove that the selected workspace is coherent for that adapter invocation. A wake that cannot start in the intended workspace is only a failed delivery attempt, not a healthy liveness path.