fix(conversations): fail closed on append-back item loss (#837)

[leseb]

Summary

Non-streaming Responses calls tied to a conversation_id persist their input/output items after the turn, but that append-back logged and swallowed any persistence error and still returned 200, silently dropping items so the next turn rehydrated an incomplete history (#837). This fails closed at the durability boundary: an item-insertion failure now propagates (the error reaches on_response_body before the buffered body is released, so under the default failure_mode: closed the body is withheld and the turn aborts instead of hiding the loss), while a post-commit message-cache refresh failure is logged and tolerated because that cache is a self-healing projection and failing would drive a retry that duplicates the id-less input items. A fault-injecting ConversationItemStore proves item-insert failure returns Err and message-cache refresh failure returns Continue.

Related issue

Closes #837

Validation

• Unit tests — cargo test -p praxis-ai-apis (2590 passing), incl. on_response_body_surfaces_item_insert_failure (→ Err) and on_response_body_tolerates_message_cache_failure (→ Continue)
• Integration or functional tests — n/a: no new capability; existing openai_conversations functional suite is unaffected (store-failure injection is not reachable through the proxy)
• make lint (and make build)

Checklist

• I reviewed every changed line and can explain the change.
• New capabilities include an example config and functional example test. — n/a (bug fix, no new capability/config)
• User-facing behavior and generated documentation are updated. — n/a (internal durability behavior; code comments updated)
• Performance-sensitive changes include appropriate benchmark or load-test evidence. — n/a
• Commits are signed and include a Signed-off-by trailer.

Breaking changes

Under the default failure_mode: closed, a conversation whose items fail to persist now aborts the turn (withheld body) instead of returning a success that hides the loss; operators wanting the prior best-effort behavior can set failure_mode: open on the filter. The transient message-cache stale window is unchanged — fully closing it (atomic item-insert + projection) is tracked separately.