SMTP CHUNKING (BDAT) incorrectly applies DATA dot-stuffing and alters message content

**Describe the bug**

When SMTP CHUNKING is enabled with `mail.smtp.chunksize` and the server advertises `CHUNKING`, Angus sends the message through `BDAT` but still applies DATA dot transparency. Lines beginning with `.` therefore gain an extra dot even though BDAT has no dot-stuffing/unstuffing step.

This silently changes the submitted message content.

**To reproduce**

Tested with:

- `org.eclipse.angus:angus-mail:2.0.5`
- Jakarta Mail API 2.1.5
- SMTP over a deterministic loopback wire server
- `mail.smtp.chunksize=31`

1. Have the server advertise CHUNKING in its EHLO response:

```text
250-smtp.example.test
250 CHUNKING
```

2. Send a message whose serialized body contains:

```text
first line
.leading dot
.
last line
```

3. Read exactly the number of octets declared by each `BDAT ` command and concatenate the chunks.

Observed BDAT content:

```text
first line
..leading dot
..
last line
```

The transaction itself succeeds because each BDAT size describes the already-altered bytes.

**Expected behavior**

RFC 3030 BDAT transfers the declared number of message octets and does not use DATA's dot transparency. The captured content should therefore retain `.leading dot` and `.` exactly.

https://www.rfc-editor.org/rfc/rfc3030

**Likely cause**

In Angus 2.0.5, `SMTPTransport.BDATOutputStream` extends `SMTPOutputStream` and wraps `ChunkedOutputStream`. `SMTPOutputStream` is the DATA stream and inserts another `.` whenever a dot occurs at the beginning of a line.

Canonical CRLF handling may still be required, but BDAT must not inherit DATA dot-stuffing behavior.

**Additional context**

Found while investigating negotiated PIPELINING and CHUNKING for bbottema/simple-java-mail#699. A local wire-level characterization test consistently reproduces the content change.