Four structurally different agent guardrail triggers share one generic "please confirm" message, including one where the write already succeeded #2986

Problem

A user really can see "nothing happened, please confirm" after a write genuinely succeeded (confirmed via the #2281 fabricated-id case and its dedicated regression test), but the specific fear of that causing a second real duplicate write is largely defused by two independent mechanisms the sweep didn't account for: update_node is classified IdempotentWrite (a retry converges rather than duplicates), and create_node gets a second, live-retrieval-based duplicate-entity guard (mentioned_entity_duplicated_by) beyond the exact-args cross-turn guard. So this is a real but low-frequency, low-consequence confusing-message papercut, not a medium-severity data-integrity risk.

Root cause

CONFIRMATION_REQUEST (packages/agent/src/local_agent/agent_loop.rs:1104) is substituted for the model's response in four structurally different situations: zero tool calls at all (anti-fabrication), a fabricated nodespace:// id where the underlying write genuinely succeeded but the model narrated the wrong id, a narrated-as-text tool call, and a write that persisted zero fields. In the fabricated-id case specifically (line ~2503, with its own doc comment and a dedicated regression test modeling bug #2281), a node was actually created/updated, yet the user sees text reading exactly as if nothing had happened.

Suggested fix

Split CONFIRMATION_REQUEST into distinct messages for the "nothing happened" cases (zero tool calls, narrated-as-text) versus the "a write genuinely succeeded but was mis-narrated" case (fabricated id, zero-fields-persisted), so a user isn't told "please confirm" when a real write already went through.

Found via the 2026-09-25 full-repo code sweep (finding #40 of 84 in CODE_SWEEP_FINDINGS_2026-09-25.md). Severity: low. Category: practical-ux.