feat: add image_pinned to skip registry rewrite for custom images

.design/a2a-multi-turn-lifecycle.md

@@ -0,0 +1,81 @@
+# A2A Bridge: Multi-Turn Task Lifecycle
+
+**Status:** Implementing
+**Created:** 2026-06-05
+**Related:** [a2a-bridge-design.md](./a2a-bridge-design.md)
+
+---
+
+## 1. Problem
+
+The A2A bridge treats the first content message from a Scion agent as the final
+response and immediately marks the task as `completed`, closing all streaming and
+push notification subscriptions. This breaks multi-turn agent interactions where:
+
+- An agent asks a clarifying question (`waiting_for_input` → user replies → agent continues)
+- An agent sends progress updates before the final answer
+- An agent emits interim artifacts during a long-running task
+
+The bridge's TODO at `bridge.go:633` explicitly acknowledges this: *"treats any
+non-state-change message as a terminal response."*
+
+## 2. Design
+
+### Current behavior (bridge.go dispatchToActiveTask)
+
+```
+Agent content message → mark task completed → broadcast final event → close subscriptions
+Agent state-change    → map to A2A state → broadcast → close if terminal
+```
+
+### New behavior
+
+```
+Agent content message → broadcast as status update with message → keep task alive
+Agent state-change    → map to A2A state → broadcast → close only if terminal
+```
+
+The key insight: **task lifecycle should be driven by agent state changes, not by
+content messages.** Content messages are data within a turn; state changes are
+lifecycle events. The bridge already correctly handles state changes — it just
+needs to stop prematurely closing on content.
+
+### State mapping (unchanged, already correct)
+
+| Scion Activity | A2A Task State | Terminal? |
+|---|---|---|
+| WORKING / THINKING / EXECUTING | working | No |
+| WAITING_FOR_INPUT | input-required | No |
+| COMPLETED | completed | Yes |
+| ERROR / STALLED / LIMITS_EXCEEDED | failed | Yes |
+
+### Changes required
+
+**bridge.go — dispatchToActiveTask():**
+Replace the `else` branch (lines ~633-675) that auto-completes on first content.
+Instead:
+1. Translate the message to A2A format
+2. Broadcast as a `StatusUpdate` with state=working and the message attached
+3. Broadcast any artifacts
+4. Do NOT update task state or close subscriptions
+
+**stream.go — StreamEvent:**
+No changes needed. `StatusUpdate` already supports carrying a message payload with
+`Final: false`.
+
+**translate.go:**
+No changes needed. `MapActivityToTaskState` already maps `WAITING_FOR_INPUT` →
+`input-required` correctly.
+
+## 3. Testing
+
+- Test: agent sends content message → task stays in `working` state
+- Test: agent sends two content messages → both are broadcast, task still alive
+- Test: agent sends content then state-change to `completed` → task completes
+- Test: agent goes `waiting_for_input` → task transitions to `input-required`
+- Regression: single-turn blocking mode still works (waiter receives first content)
+
+## 4. Scope
+
+- In: dispatchToActiveTask content handling
+- Out: follow-up message routing (PR 2), capability advertisement (PR 3)

.design/a2a-task-followup.md

@@ -0,0 +1,69 @@
+# A2A Bridge: Follow-Up Messages on Existing Tasks
+
+**Status:** Implementing
+**Created:** 2026-06-05
+**Related:** [a2a-bridge-design.md](./a2a-bridge-design.md), [a2a-multi-turn-lifecycle.md](./a2a-multi-turn-lifecycle.md)
+
+---
+
+## 1. Problem
+
+The A2A protocol supports multi-turn conversations via `contextId` (session) and
+`taskId` (turn). A client should be able to:
+
+1. Send an initial `message/send` → get a taskID back
+2. Wait for the agent to respond (possibly with `input-required`)
+3. Send a follow-up `message/send` with the same `taskID` → continue the conversation
+
+Currently, `SendMessage` always creates a new task, even when `taskID` is provided
+in the params. The `SendMessageParams` struct already has a `TaskID` field, but
+it's unused in the dispatch logic.
+
+## 2. Design
+
+### Current behavior
+
+```
+message/send {taskId: "abc"} → ignored, creates new task → new taskID returned
+```
+
+### New behavior
+
+```
+message/send {taskId: "abc"} → look up task "abc" → verify not terminal →
+  resolve agent from task → send message to agent → return existing task
+```
+
+### Changes
+
+**bridge.go — SendMessage():**
+At the top of the function, before creating a new task:
+1. Check if `taskID` is non-empty (from `SendMessageParams.TaskID`)
+2. If set, look up the task from the store
+3. Verify the task belongs to the requesting project/agent (authorization)
+4. Verify the task is not in a terminal state
+5. Resolve the agent from the task's stored `AgentID`
+6. Send the message to the agent
+7. Update task state to `working` if it was `input-required`
+8. Return the existing task (not a new one)
+
+### Context vs Task
+
+The A2A spec uses `contextId` to group related tasks into a session, and `taskId`
+to identify individual turns. For follow-ups:
+- `taskID` provided → continue that specific task/turn
+- Only `contextID` provided → new task within the existing session (current behavior works)
+- Neither → new context + new task (current behavior works)
+
+## 3. Testing
+
+- Test: message/send with valid taskID routes to same agent
+- Test: message/send with terminal-state taskID returns error
+- Test: message/send with unknown taskID returns error
+- Test: message/send with taskID from different project returns error
+- Test: task state transitions from input-required to working on follow-up
+
+## 4. Scope
+
+- In: Follow-up routing via taskID in SendMessage
+- Out: Multi-turn lifecycle changes (PR 1), capability updates (PR 3)