revert /reply to old behavior when full conversation provided

[tlongwell-block]

Allow passing full conversation to /reply if needed. This supports the previous behavior of the /reply endpoint before the session required overhaul as part of the agent manager work. This is required for some uses of goose-server where session contents may have more than one source of truth, like the goose slackbot.

[DOsinga]

I think we do need to keep the full conversation in the loop

[DOsinga]

this doesn't strike me as quite right; we keep a shadow administration of the messages here I think just for tracking purposes. we should probably move that to agent, but until we do, we should in the block above retrieve the conversation so far from the db if it is not given and then call the agent only with the user message

[tlongwell-block]

/goose

[github-actions]

Summary: This PR restores the ability for external integrations (like the Slack bot) to provide their own conversation history when calling /reply, while maintaining backward compatibility for the desktop UI. The API change from messages to user_message + optional conversation_so_far is well-designed and the implementation is correct.

🟡 Warnings

1. Silent failure on replace_conversation may cause stale context (crates/goose-server/src/routes/reply.rs:287-293)

   When conversation_so_far is provided but SessionManager::replace_conversation fails, the code logs a warning and continues:

   if let Err(e) = SessionManager::replace_conversation(&session_id, &conv).await {
       tracing::warn!(
           "Failed to replace session conversation for {}: {}",
           session_id,
           e
       );
   }

   However, agent.reply() subsequently reads conversation from SessionManager::get_session() (see crates/goose/src/agents/agent.rs). If the replace failed, the agent will use the old session data instead of the caller-provided conversation.

   For external integrations where conversation_so_far is the source of truth, this could lead to the agent responding with incorrect context. Consider either:

   • Returning an error to the caller when replace fails, or
   • Documenting this as a known limitation for callers

✅ Highlights

• Clean API design: Separating user_message from conversation_so_far makes the intent clear - the new message vs the history
• Backward compatible: Desktop UI continues working with just user_message while external integrations can use conversation_so_far
• Test updated correctly: The integration test at reply.rs:482-488 properly uses the new API structure
• OpenAPI spec regenerated: Following project conventions

---

Review generated by goose