Data packets are not padded to 16 bytes (RFC/WireGuard whitepaper §5.4.6), exposing exact inner packet lengths

`format_packet_data` in `boringtun/src/noise/session.rs` encrypts the plaintext at its original length, with the comment:

```rust
// TODO: spec requires padding to 16 bytes, but actually works fine without it
```

The comment is accurate about interoperability; nothing breaks, because the receiver takes the length from the decrypted inner packet's own header and never inspects the padding. That is also why the omission is invisible: there is no peer, and no test, that would fail.

The consequence is on the wire. Sweeping an inner packet across every residue mod 16, `wireguard-go` pads to the next multiple of 16 in all 33 cases while boringtun emits `outer = inner + 32` throughout, so the outer datagram size determines the inner packet size exactly. WireGuard's padding exists to blunt that; here it is absent.

This appears to be already fixed downstream: an audit of Mullvad's boringtun-derived implementation reported the same omission in early 2026 and it was corrected in that fork. This issue is only to note that upstream still carries it.

Start in boringtun/src/noise/session.rs at format_packet_data, then read WireGuard whitepaper §5.4.6 and inspect nearby session tests or packet-length handling. Done means encrypted data follows the required 16-byte padding rule across inner packet lengths while remaining interoperable with peers.

Written by the indexing model from the issue text.