Integration coverage: MCUboot serial-recovery MCUmgr params negotiation (Auto buf_size) #120

mcu-tools/mcuboot#2746 — "boot: boot_serial: add optional mcumgr parameters command" (merged) — gives MCUboot's serial-recovery SMP server an optional MCUmgr parameters command (CONFIG_BOOT_MGMT_MCUMGR_PARAMS). This is a behavior change for us: until now MCUboot serial recovery never advertised params, and we hardcode that assumption —

• src/smpclient/transport/serial/encoded.py (Auto docstring): "For servers that do not advertise MCUmgr params (e.g. MCUboot serial recovery)…"
• tests/integration/test_serial_recovery.py / test_serial_recovery_raw.py: "recovery does not advertise MCUmgr params", so they pass an explicit BufferSize(buf_size=1024) / pin mtu.

With the option enabled, a recovery server can report {buf_size, buf_count: 1}. SMPClient._initialize already consumes that (src/smpclient/__init__.py:556): it issues MCUMgrParametersRead and, on success, calls transport.initialize(buf_size); on an SMP error it warns, and on timeout it warns and the transport simply keeps its existing buffer size (the implicit fallback). What's missing is any integration coverage of the success path against a bootloader recovery server.

Blocked on

intercreate/smp-server-fixtures#10 — the recovery fixtures must be rebuilt with CONFIG_BOOT_MGMT_MCUMGR_PARAMS=y, and that issue also decides how the manifest surfaces the recovery server's advertised buf_size/buf_count (which differs from the fixture's app-side buf_size).

Harness work (smpclient side)

1. Re-vendor the updated serial_recovery + serial_recovery_raw (mps2) fixtures once published — refresh tests/fixtures/smp-server/{manifest.json,SHA256SUMS,VERSION} the way test(integration): MCUboot raw serial recovery (SMPSerialRawTransport) #119 did.

2. Cover the negotiated path (in addition to, not replacing, the explicit-BufferSize path — params remain optional, so params-less recovery servers must still work). In test_serial_recovery.py and test_serial_recovery_raw.py, after re-entering recovery, assert MCUMgrParametersRead now succeeds with buf_count == 1 and buf_size equal to the recovery server's advertised value (from the manifest field added by feat: add shell management group #10), and that Auto negotiation produces the expected cap:

   • encoded console recovery → max_unencoded_size == buf_size − 4 (the length prefix + CRC16 share the decoded frame);
   • raw recovery → max_unencoded_size == buf_size (no base64/length/CRC framing; the transport inherits the SMPTransport base that uses buf_size directly).

   The advertised value is a decoded ceiling (mcuboot's BOOT_SERIAL_MAX_RECEIVE_SIZE, default 1024), so this finally pins the encoded-vs-decoded buf_size question empirically against a real recovery server.

3. Update the now-outdated assumptions. The "recovery does not advertise MCUmgr params" wording in the encoded.py Auto docstring and in both recovery tests is no longer universally true — qualify it (params are now optionally advertised by recovery, gated on the bootloader Kconfig).

4. Raw test: test_serial_recovery_raw.py currently pins the cap via QemuSocketSerialRawTransport(..., mtu=mtu). Add a leg that lets the client read buf_size and asserts the resulting max_unencoded_size, alongside the fixed-mtu parametrization.

Acceptance

A recovery upload runs with the buffer size negotiated from the bootloader's params (not the explicit BufferSize / mtu fallback), for both encoded and raw recovery, green in CI — while the params-less recovery path still passes.

Refs: mcu-tools/mcuboot#2746, #81, #118 / #106 (raw recovery), #119 (raw-recovery test scaffolding this extends).