fix(buddy): say what actually disables the new-conversation control

[daniilperkin]

What

Three doc blocks still described the round before the mid-answer stop. The new-conversation button's header said it is disabled mid-turn because newConversation "cannot call back a request already streaming into it", and the conversation list's prop doc plus its binning paragraph said picking or binning mid-turn is refused and the controls stand down for that window. None of that is true anymore — the move stops the running answer itself (see stopRunningTurn) and stays on offer mid-answer; the list is disabled only for an open, a greeting, or a decision in flight (and in team mode), never for a running answer.

Changes

• BuddyNewConversationButton — the header now lists the caller's actual disable terms (team mode, empty conversation, an open or greeting in flight, a proposal decision in flight) and says mid-answer it stays live.
• BuddyConversationList — the disabled prop doc matches the caller's condition and points at stopRunningTurn for what happens to a running answer; the binning paragraph now says the session stops a reply still streaming into the conversation being binned, and leaves a running answer in another conversation alone.

Comment-only; no behavior change.

Verification

• prettier --check + eslint on the two touched files — pass
• npm run build — pass
• vitest run on the suites covering the touched files (BuddyConversationList, BuddyPage, BuddyPage.address, BuddyPage a11y) — pass

Notes

Found in the post-merge audit of the buddy-surface PRs (#318 frontend side). hotfix/ branch, targets dev.