Merge worktree-hooks-b-bash-seam into worktree-hooks-c-interception

Bring the interception-seams branch onto current master (via A→B). The
substantive reconciliation is master's compaction `agent/pre-step` serial seam
meeting C's interception seams:

- types.ts: keep BOTH master's `agent/pre-step` AND C's new interception events
  (`agent/prompt-submit`, `agent/session-start`, `agent/turn-continuation`→
  `ContinuationDecision`); drop the turn-mirror declarations (removed on A).
- loop.ts: the merged per-turn order is `turn/start` → per queued msg
  `agent/prompt-submit` (rewrite/inject/block) → (fully-blocked ⇒ zero-step
  `rejected`) → per step: drain steering → assemble system prompt →
  `agent/pre-step` (compaction, OUTSIDE the step) → `step/start` → single
  `deriveMessages()` → model → tools/pre-execute·dispatch·post-execute. No
  turn-mirror emits; `closeTurn()` is the A-simplified single-call form.
- Docs (architecture, core.md, agent/agent-loop READMEs, catalog) reconciled to
  show C's interception seams alongside `agent/pre-step`, no turn/step mirrors.
- rfc/README: dropped the stale `proposed/` compaction row (master moved that RFC
  to implemented/); kept C's new `pre-tool-input-rewrite` proposed row.
- interception.spec.ts: migrated its two `agent/turn-end` reason collectors to
  the `turn/end` session event, and ADDED a cross-test proving a
  `prompt-submit` rewrite + additionalContext is VISIBLE to an `agent/pre-step`
  listener on the same turn — pinning the merged seam ordering (compaction sees
  the post-prompt-submit surface, not stale history).

packages/bash/tool-bash/README.md

@@ -40,9 +40,9 @@ These tools own how their calls render in a UI (an editor's tool-call card) via
 
 When a background task finishes, a short notice is injected into the owning agent's session (`agent.inject()`, source `{kind: 'plugin', plugin: 'tool-bash'}`). The owning agent is found by its session token: the listener reads `ctx.bash.ownerOf(task.id)` and scans `ctx.get('agents')?.list()` for an agent whose `session.header.id` matches (read via `ctx.get` — `onTaskDone` runs on the bash fiber, a foreign fiber, so the `ctx.agents` proxy would throw). If no live agent carries that token — e.g. the owning session disconnected and its agent was disposed while the task ran on — the notice is dropped cleanly. Injection is **durable context for the next model request, not a wake-up** — an idle agent stays idle until something sends a message. That's why the tool descriptions tell the model to poll with `bash_output`.
 
-## Trusted-plugin boundary: env / stdin are never model-driven
+## The tool builds its request from named args only
 
-The `BashExecRequest` seam carries optional `stdin` and `env` (a **trusted-plugin surface** used by the hooks bridges to feed a hook command its JSON payload and `CLAUDE_*` env). This tool deliberately **never** threads model input into either: its request is built from `command`/`workdir`/`timeoutMs`/`signal`/`owner` only, so a model that includes `env` or `stdin` keys in its tool arguments has them ignored — it cannot smuggle an environment variable or stdin payload past `dsh-bash-local`'s credential scrub. A regression guard (the "trusted-plugin boundary" tests) drives the real tool with adversarial args and asserts the resulting request carries neither field. See [the trusted-plugin RFC](../../../docs/rfc/implemented/architecture/2026-06-30-bash-stdin-env-trusted-plugin-surface.md).
+The `BashExecRequest` seam carries optional `stdin` and `env`, used by the hooks bridges to feed a hook command its JSON payload and `CLAUDE_*` env. This tool does **not** expose them as parameters: its request is built from `command`/`workdir`/`timeoutMs`/`signal`/`owner` only, so a model that includes `env` or `stdin` keys in its tool arguments has them ignored. This is not a trust boundary — a model already has equivalent power through shell syntax (`FOO=bar cmd`, a heredoc), and the real defense against leaking the harness's ambient secrets is `dsh-bash-local`'s credential scrub, which works regardless. A regression guard drives the real tool with those extra args and asserts the resulting request carries neither field — its job is to catch a future refactor that blindly spreads `...args` into the request (which would silently forward model input into the post-scrub `env` merge), not to defend a wall. See [the bash-stdin-env RFC](../../../docs/rfc/implemented/architecture/2026-06-30-bash-stdin-env-trusted-plugin-surface.md).
 
 ## Permissions
 

packages/bash/tool-bash/tests/tools.spec.ts

@@ -864,14 +864,18 @@ describe('tool-owned UI presentation (presentCall / presentResult)', () => {
   })
 })
 
-describe('trusted-plugin boundary: the model-facing bash tool never sets env/stdin', () => {
+describe('the model-facing bash tool builds its request from named args only (no {...args} forward)', () => {
   /**
    * Records every {@link BashExecRequest} the consumer hands to `resolve()`, so a
-   * test can assert what the model-facing tool DID and DID NOT forward. `stdin`
-   * and `env` are a TRUSTED-PLUGIN surface (in-process plugins only); the `bash`
-   * tool must never thread model-supplied input into them, even when the model
-   * smuggles extra keys into the tool arguments. Foreground `run()` returns a
-   * canned result; `start()` is unused here.
+   * test can assert what the model-facing tool DID and DID NOT forward. The `bash`
+   * tool does not expose `stdin`/`env` as parameters (bash syntax already gives a
+   * model that power), so it must build its request from named args only and
+   * never spread unknown tool-call keys into it. This guard's job is to catch a
+   * future refactor that blindly forwards `...args` — which would silently thread
+   * model input into the post-scrub `env` merge — NOT to defend a trust boundary
+   * (the credential scrub in dsh-bash-local is the security control; see the
+   * bash-stdin-env RFC). Foreground `run()` returns a canned result; `start()` is
+   * unused here.
    */
   class RecordingBashExecutor extends BashExecutor {
     readonly requests: BashExecRequest[] = []
@@ -911,14 +915,16 @@ describe('trusted-plugin boundary: the model-facing bash tool never sets env/std
     return { ctx, bash: ctx.bash as RecordingBashExecutor }
   }
 
-  it('does not forward env/stdin even when the model smuggles them as extra arguments', async () => {
+  it('does not forward env/stdin even when the model includes them as extra arguments', async () => {
     const { ctx, bash } = await setupRecording()
-    // Adversarial args: the model includes `env` and `stdin` keys (and a
-    // credential-shaped value) hoping they reach the executor. The bash tool's
-    // schema ignores unknown keys, and execute() builds the request from only
-    // command/workdir/timeoutMs/signal — so the recorded request carries NEITHER.
+    // Extra args: the model includes `env` and `stdin` keys hoping they reach the
+    // executor. The bash tool's schema ignores unknown keys, and execute() builds
+    // the request from only command/workdir/timeoutMs/signal — so the recorded
+    // request carries NEITHER. (Not a security wall — the model could set an env
+    // var or feed stdin via shell syntax anyway; this just keeps the request
+    // shape honest so a future `...args` spread can't silently forward input.)
     await ctx.tools.execute({
-      callId: CallId('boundary-1'),
+      callId: CallId('no-forward-1'),
       name: 'bash',
       arguments: {
         command: 'echo hi',
@@ -937,9 +943,9 @@ describe('trusted-plugin boundary: the model-facing bash tool never sets env/std
   it('a background bash call likewise carries no env/stdin', async () => {
     const { ctx, bash } = await setupRecording()
     // start() throws in this recorder, but resolve() runs first and records the
-    // request — which is all this boundary assertion needs.
+    // request — which is all this no-forward assertion needs.
     await ctx.tools.execute({
-      callId: CallId('boundary-2'),
+      callId: CallId('no-forward-2'),
       name: 'bash',
       arguments: {
         command: 'sleep 1',