feat(cli): add --cc and --bcc to e2a send and e2a reply

[AmirF194]

Summary

e2a send/e2a reply had no --cc/--bcc, even though the REST API, both
SDKs, and the MCP send_message tool already carry cc/bcc on send. Adds
the flags to both commands, wired straight onto the existing request fields.

Client surface checklist

• OpenAPI spec + generated types refreshed (make generate is clean): not touched, cc/bcc were already on SendEmailRequest/ReplyRequest
• TypeScript SDK: not touched, for the same reason
• Python SDK: not touched, for the same reason
• CLI command or flag in cli/src/commands/ + wired into cli/src/bin/e2a.ts
• MCP tool: not touched, send_message/reply_message in mcp/src/tools/legacy.ts already accept cc/bcc
• Tests at each surface above (positive + at least one negative-path / regression case)

Skipped rows: Go handler, migration. No server-side change, the fields already exist.

Operational risk

None. Client-only change, no new server behavior.

Test plan

• npm run test:coverage --workspace @e2a/cli: 321/321 passed (5 new). The 5 new
  cases fail on unmodified main (tsc rejects cc/bcc as unknown SendOptions/
  ReplyOptions properties) and pass on this branch.
• npm run build --workspace @e2a/cli: clean.
• Manual: built CLI, ran e2a send with 51 combined --to/--cc/--bcc recipients,
  confirmed it exits 2 (usage) before any request is sent, per the issue's ask.
• Not checked: a live end-to-end send through a running server (this environment
  has no e2a instance to send through); the SDK call shape is covered by the unit
  tests above instead.

The over-cap check only applies to send; reply's primary recipients come
from the thread being replied to, so the CLI cannot compute the true combined
total the way it can for send.

e2a forward does not exist as a CLI command, so the issue's suggestion to
check it there does not apply.

Fixes #816

[jiashuoz]

LGTM — approving.

Verified against the code before approving:

• Generated SendEmailRequest/ReplyRequest already carry optional cc/bcc, and SendEmailInput/ReplyInput inherit them via Omit, so the pass-through is type-valid with no SDK changes.
• The server cap is 50 combined across to+cc+bcc (internal/httpapi/outbound.go, maxRecipients = 50, too_many_recipients), so the CLI pre-check matches server semantics and fails with exit 2 before any request — exactly what #816 asked for.
• Skipping the pre-check on reply is correctly reasoned (thread recipients aren't knowable client-side; server stays the backstop).
• 5 new tests cover passthrough, empty-list omission, the 50/51 boundary, and reply — good negative-path and boundary coverage.
• No CHANGELOG entry needed per-PR; entries are batched at release time per repo convention.

Two nits, non-blocking:

1. Help-text placement (cli/src/bin/e2a.ts): the cap note is a continuation line under --json, so it reads as part of the --json description. Consider attaching it to the --bcc line or making it a standalone note under the send block.

2. Duplicated constant: MAX_COMBINED_RECIPIENTS = 50 mirrors the server's maxRecipients. If the server value ever changes, the CLI message drifts (harmlessly — the server error carries max_recipients in details). A one-line comment pointing at the server source would help future maintainers.

[AmirF194]

Thanks for the quick review and merge. Glad the SendEmailInput/ReplyInput types lined up cleanly with the CLI wiring.