mgmt/mcumgr/transport: uart: assert UART MTU fits the netbuf

[JPHutchins]

Summary

The mcumgr UART SMP transport documents MCUMGR_TRANSPORT_UART_MTU <= MCUMGR_TRANSPORT_NETBUF_SIZE + 2 in Kconfig.uart as a "must satisfy" relation, but only BUILD_ASSERT(UART_MTU != 0) is actually enforced. Since the transport reassembles the base64-decoded SMP frame into one NETBUF_SIZE buffer, a UART_MTU larger than the netbuf can never be used — yet a misconfiguration is silent until runtime. This adds the missing BUILD_ASSERT, mirroring the existing one.

• Default configs satisfy it with margin (256 ≤ 386), so no in-tree config breaks.
• smp_uart.c depends on UART_MCUMGR && !UART_MCUMGR_RAW_PROTOCOL, so all referenced symbols are always defined here.

Context

Found while investigating what an SMP serial client may send (mcu-tools/mcuboot#2746, intercreate/smpclient#81). The advertised/buf_size value is the decoded netbuf; the on-wire frame is ~1.37× larger (base64 + line framing), decoded fragment-by-fragment into the netbuf — so the netbuf is the real per-transaction ceiling. Confirmed empirically against native_sim/QEMU/mps2 servers (a NETBUF_SIZE − 4 message round-trips while the encoded frame exceeds NETBUF_SIZE).

Open questions (intentionally out of this PR — see the plan doc commit)

• The second documented relation, RX_BUF_COUNT * RX_BUF_SIZE >= UART_MTU, looks like a throughput heuristic rather than a hard requirement (fragments are decoded + recycled incrementally), so asserting it could reject configs that work today. Left for discussion.
• UART_MTU's get_mtu is never called on the UART path; the help text ("sent and received") may warrant clarification.

Note: the [not for upstream] plan commit is a design/analysis doc for review and should be dropped before any upstream submission.