getRecipients adds the conversation contact to CC when replying to a third party

### Describe the bug

When an email conversation contains a message from someone other than the conversation contact, `getRecipients` adds the conversation contact to the CC list. Replying to that third party therefore copies the original contact in, **without the agent choosing it and without an obvious signal**.

Call site, unchanged between v4.13.0 and v4.17.1:

```js
// chatwoot/chatwoot, app/javascript/dashboard/components/widgets/conversation/ReplyBox.vue:1263
const { cc, bcc, to } = getRecipients(
this.lastEmail,
conversationContact,
inboxEmail,
forwardToEmail
);
```

### To reproduce

1. An email conversation exists with contact A.
2. An inbound message arrives on the same thread from B, a different address — a supplier, contractor or colleague who has joined the chain.
3. The agent replies to B's message.
4. Observe **A pre-populated in CC**.

### Expected behaviour

Recipients for a reply should derive from the message being replied to. The conversation contact should not be added automatically when they were not a party to that message. If the current behaviour is deliberate for some flows, it would be safer as an explicit action the agent takes rather than a default.

### Impact

**Confidentiality.** The realistic case is a contractor or supplier discussing trade pricing or a referral arrangement on a thread the end customer also started. The customer receives a copy. No agent action causes it and nothing draws attention to it, so it can recur for a long time before anyone notices.

We treat this as the highest-severity issue we have found in our deployment.

### Related — worth reading before triaging

There is active work in this exact function, and **it is the inverse of this bug**:

- #67 / #68 here — `getRecipients` *drops* incoming To-line recipients from the reply CC.
- chatwoot/chatwoot#15581 — the downstream half of that fix.

Those are about recipients wrongly falling **out** of CC. This report is about a recipient wrongly being put **into** CC. They touch the same branch, so it is probably worth settling the intended rule for that branch once rather than twice — a fix for one could easily mask or worsen the other.

### Environment

Self-hosted Chatwoot v4.13.0, Docker. Behaviour re-checked against the v4.17.1 tag.

### Offer

We have run a server-side mitigation in production since 26 August. Happy to work up a PR here, and happy to coordinate with whoever is on #68 so the two do not collide.

Trace getRecipients from app/javascript/dashboard/components/widgets/conversation/ReplyBox.vue:1263 and inspect the recipient branch involved when replying to a third party. Compare the intended behavior with #67, #68, and chatwoot/chatwoot#15581; done means the conversation contact is not added to CC unless they were a recipient of the message being replied to, without regressing the related CC handling.

Written by the indexing model from the issue text.