fix: ask response persistence lies to the engine after AddMessage fails, dropping assistant turns

[sam-saffron-jarvis]

What changed

• Return the store.AddMessage error from ask response persistence instead of reporting success after a failed assistant write.
• Keep output-tool response tracking aligned with the engine callback contract by only marking the response handled after persistence succeeds.
• Added a focused regression test where the first assistant AddMessage fails and the engine redelivers the assistant through TurnCompletedCallback, preserving the durable turn.

Why this is high-value

term-llm ask uses ResponseCompletedCallback to persist assistant/tool-call turns before tool execution. When that write failed transiently, ask returned nil, so the engine believed the assistant turn was already durable and omitted it from the later turn callback. That silently corrupted saved sessions by keeping tool results/metrics while dropping the assistant message that caused them. Returning the write error activates the engine's existing fallback path.

Validation

• go test ./cmd -run 'TestAskResponsePersistenceErrorRedeliversAssistantToTurnCallback|TestEnsureOutputTool|TestRunOutputTool' -count=1
• go build ./...
• go test ./...
• git diff --check