fix: --new-session implies --new-conversation for agent invoke

[Copilot]

The backend derives sessions from conversation IDs, so --new-session alone reuses the existing conversation and gets back the same session ID. This makes --new-session ineffective unless paired with --new-conversation.

Changes

• invoke.go: Pass newConversation || newSession as the forceNew parameter when resolving conversation IDs in both responsesRemote() and responsesLocal()
• invoke_test.go: Add tests covering three flag combinations: --new-session alone (forces both), --new-conversation alone (session unchanged), and both together (redundant but valid)

// Before
convID, err := resolveConversationID(ctx, azdClient, name, a.flags.conversation, a.flags.newConversation, ...)

// After
convID, err := resolveConversationID(ctx, azdClient, name, a.flags.conversation, a.flags.newConversation || a.flags.newSession, ...)

[trangevi]

What do we think the user expectation actually is here? If a user is expecting that they'd keep the same conversation on a new session, this will break that expectation.

If I saw the conversation correctly, manually providing a session ID will not generate a new conversation ID, so should we be doing that? So a user would be required to pass both new flags to hit that path, instead of an implicit handling with no way to keep the conversation on a new session?

[microsoft-github-policy-service]

Hi @@copilot. Thank you for your interest in helping to improve the Azure Developer CLI experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[jongio]

The fix addresses a real problem: the backend derives sessions from conversations, so --new-session alone reuses the existing conversation and gets back the same session. The || approach makes the flag work.

Two items to resolve before merging:

1. @trangevi's design question is still open. This removes the ability to start a new session while keeping a conversation. If that's intentionally unsupported, the --new-session flag help text should say so. It currently reads "Force a new session (discard saved one)" with no mention of conversations. Note: explicit --conversation <id> still overrides the force-new logic, so power users have an escape hatch.

2. The || a.flags.newSession logic is duplicated at two call sites (responsesLocal and responsesRemote). Consider resolving the implication once in Run():

   if a.flags.newSession {
       a.flags.newConversation = true
   }

   This keeps both paths in sync and prevents drift if a third path is added.

Also: this is a draft PR with a "no-recent-activity" label. The open design question from @trangevi should be addressed before marking ready.

[jongio]

This || is also in responsesRemote. Consider resolving the implication once in Run() so both code paths stay in sync.