docs(notes): scope the reminder framing binding claim to the tools

The Consequences and the alternative treated the task's Session binding as the
constraint on who writes the prompt. The package README records that the same
binding is not caller authorization, and the Web task detail writes the prompt
through the same service, so both sentences now name the prompt's writing paths
and the binding's actual scope instead.

.agents/notes/implemented/architecture/2026-09-24-scheduled-message-framing.i18n.yaml

@@ -12,8 +12,8 @@
   en: 297f1fdd04894f95
   zh: 4ac560e27b6f0aed
 /agent-note-delivered-reminders-are-framed-as-scheduled-messages-from-the-user/alternatives-considered:
-  en: c139d2266367e31a
-  zh: 1c8c051f067c0b3c
+  en: 8074a2b9b9f5d782
+  zh: 1604b7ee5d34375e
 /agent-note-delivered-reminders-are-framed-as-scheduled-messages-from-the-user/consequences:
-  en: bff6395d6bc71837
-  zh: f4f33489e0a0994a
+  en: d96bc209cece929e
+  zh: 88a877d0fe8983ff

.agents/notes/implemented/architecture/2026-09-24-scheduled-message-framing.md

@@ -16,7 +16,7 @@ The fixed line states the origin of the message: a schedule bound to that Sessio
 
 ## Alternatives considered
 
-**Keep the untrusted-content instruction.** It asserted that the prompt was untrusted input, which the delivered message does not need: the delivery is an ordinary user-role message in the Session the schedule is bound to, and the Session binding check that scopes `schedule_create` and `schedule_update` is the part that constrains who can write the prompt.
+**Keep the untrusted-content instruction.** It asserted that the prompt was untrusted input, which the delivered message does not need: the prompt is written in the Session the schedule is bound to — by the model through `schedule_create` and `schedule_update`, or by the user in the Web task detail — and the delivery is an ordinary user-role message there.
 
 **Change only the recurring batch line.** One-shot and recurring delivery would then disagree about the origin of the same kind of message, and each later wording change would need both renderers edited separately. Both paths now read one constant.
 
@@ -24,4 +24,4 @@ The fixed line states the origin of the message: a schedule bound to that Sessio
 
 Model-visible reminder text changes for both delivery paths, so a Session log recorded before this decision reconstructs the previous framing, and the Web notice that renders a delivered message shows the new line when expanded. Nothing else moves: no session event, storage field, client code, protocol, or durable format changes, and the delivered text remains reconstructable from the log.
 
-The prompt text carries no authorship guarantee. A reminder the model creates can quote text the model read from the web, files, or command output, and that text is delivered under the user-origin line. The Session binding on `schedule_create` and `schedule_update` limits which Session's model can write the task, not where the prompt content came from. A delivery path whose prompt text can originate outside the target Session, or a decision to mark such content again, needs its own framing decision.
+The prompt text carries no authorship guarantee. It is written in the Session the schedule is bound to, by the model through `schedule_create` and `schedule_update` or by the user in the Web task detail, and a model-written reminder can quote text the model read from the web, files, or command output. The task's Session binding scopes which Session's model reaches the task; it is not caller authorization and says nothing about where the prompt content came from. A delivery path whose prompt text can originate outside the target Session, or a decision to mark such content again, needs its own framing decision.

.agents/notes/implemented/architecture/2026-09-24-scheduled-message-framing.zh.md

@@ -16,7 +16,7 @@ Status: implemented
 
 ## Alternatives considered
 
-**保留「不可信内容」指令。** 它断言提示词是不可信输入，而投递的消息并不需要这一断言：投递本身是绑定该定时任务的 Session 中的普通 user-role 消息，约束提示词写入者的是限定 `schedule_create` 与 `schedule_update` 范围的 Session 绑定校验。
+**保留「不可信内容」指令。** 它断言提示词是不可信输入，而投递的消息并不需要这一断言：提示词写在绑定该定时任务的 Session 内——由模型通过 `schedule_create` 与 `schedule_update` 写入，或由用户在 Web 任务详情中写入——投递本身就是该 Session 中的普通 user-role 消息。
 
 **只改周期批次那一行。** 单次与周期投递会对同类消息的来源给出不同说法，此后每次改措辞都要分别改两个渲染器。现在两条路径读同一个常量。
 
@@ -24,4 +24,4 @@ Status: implemented
 
 两个投递路径的模型可见提醒文本都改变，因此在该决策之前记录的 Session 日志重建出的是旧的固定文本；Web 中渲染该投递消息的通知在展开时显示新的一行。其余不动：没有 session 事件、存储字段、客户端代码、协议或持久化格式变化，投递文本仍可从日志重建。
 
-提示词文本不携带作者保证。模型创建的提醒可以把模型从网页、文件或命令输出中读到的文本原样写入，而该文本会以用户来源行交付。`schedule_create` 与 `schedule_update` 的 Session 绑定限制的是哪个 Session 的模型可以写入任务，而不是提示词内容的来源。若出现提示词文本可来自目标 Session 之外的投递路径，或决定重新标记此类内容，都需要单独决定其固定文本。
+提示词文本不携带作者保证。它写在绑定该定时任务的 Session 内——由模型通过 `schedule_create` 与 `schedule_update` 写入，或由用户在 Web 任务详情中写入——模型创建的提醒可以把模型从网页、文件或命令输出中读到的文本原样写入。任务的 Session 绑定限定的是哪个 Session 的模型能访问该任务；它不是调用方鉴权，也不说明提示词内容的来源。若出现提示词文本可来自目标 Session 之外的投递路径，或决定重新标记此类内容，都需要单独决定其固定文本。