Fix session resuming with --name parameter after SQLite migration

[goose-slackbot]

Problem

After the SQLite migration, the goose session --resume --name <session_id> command stopped working when using actual session IDs. It now only works with session descriptions, breaking backward compatibility.

Current Behavior

$ goose session --resume --name 20251001_142609
Error: No session found with name '20251001_142609'

The --name parameter used to accept both session IDs and descriptions interchangeably, but now only matches descriptions.

Expected Behavior

The --name parameter should work with both:

• Session IDs (e.g., 20251001_142609)
• Session descriptions (e.g., "My debugging session")

This maintains backward compatibility with existing user workflows.

Root Cause

In crates/goose-cli/src/cli.rs, the get_session_id function only searches by description:

async fn get_session_id(identifier: Identifier) -> Result<String> {
    // ... existing code ...
    else if let Some(name) = identifier.name {
        let sessions = SessionManager::list_sessions().await?;
        sessions
            .into_iter()
            .find(|s| s.description == name)  // ISSUE: Only matches description
            .map(|s| s.id)
            .ok_or_else(|| anyhow::anyhow!("No session found with name '{}'", name))
    }
}

Proposed Fix

Modify the search condition to check both session ID and description:

.find(|s| s.id == name || s.description == name)  // Search both ID and description

Context

This regression was identified in the #goose-dev Slack channel where multiple users confirmed the issue:

• @tlongwell reported the initial problem with example commands
• @douwe confirmed the expected behavior and suggested the --session-id workaround
• @wpfleger confirmed the regression from previous behavior

Acceptance Criteria

• goose session --resume --name <session_id> works with actual session IDs
• goose session --resume --name <description> continues to work with descriptions
• Backward compatibility is maintained
• Tests verify both ID and description matching work correctly

@goosebotgh Please open a draft PR to implement this fix.

[wpfleger96]

@goosebotgh Please open a draft PR to implement this fix, with the additional suggestion that we should use .contains() instead of exact matching on the description field to make the search more flexible and user-friendly