Support EZSPv19

[puddly]

No new useful commands in this release but MFG_STRING has been deprecated for some reason. I can't really figure out why. We rely on this manufacturing token to store the board manufacturer's name. MFG_BOARD_NAME has not been deprecated.

Overrides via XNCP_MFG_MANUF_NAME and XNCP_MFG_BOARD_NAME will continue working without issues, as they don't actually store data in manufacturing tokens.

[zigpy-review-bot]

Approve — clean EZSPv19 bump following the established per-version pattern; full test suite passes locally.

Verified against the actual SiSDK 2026.6.0 headers (installed via slt, same as the firmware-builder CI):

• ezsp-protocol.h: EZSP_PROTOCOL_VERSION 0x13 ✅
• ezsp-enum.h: SL_ZIGBEE_EZSP_CLEAR_BINDING_TABLE_ON_LEAVE = 0x006D, and it's the only new command vs 2025.12.3 ✅
• command-prototypes.h: void sl_zigbee_ezsp_clear_binding_table_on_leave(bool clear) — matches the {"clear": t.Bool} → {} schema ✅
• The 0x006D reuse is safe in bellows: getTransientKeyTableEntry last held it and was removed in v13, so the inherited v18 chain has the slot free.
• Re the MFG_STRING mystery: the deprecation isn't in ezsp-enum.h but in platform_core/.../token_manager/inc/sl_token_manager_manufacturing.h, which now splits on SL_TOKEN_MANAGER_FORMAT_LEGACY — the Series-3 branch defines TOKEN_MFG_BOARD_NAME but drops exactly TOKEN_MFG_STRING, TOKEN_MFG_BOOTLOAD_AES_KEY, and TOKEN_MFG_EZSP_STORAGE (Series 3 stores tokens as KLV keys in the SE MTP region, and those three didn't make the cut). So the three annotations match the header exactly.

[zigpy-review-bot]

Some more detail on the MFG_STRING mystery, from digging through the 2026.6.0 sources — the deprecation turns out to be broader than the enum comments suggest, and it explains the "why":

Root cause: Series 3 changed the physical token storage model. On Series 2, manufacturing tokens live at fixed flash offsets (TOKEN_MFG_STRING = SL_TOKEN_STATIC_DEVICE_TOKENS | 0x010, the bootload AES key in the lockbits page). On Series 3, tokens became KLV (key-length-value) entries in the Secure Engine's MTP region, managed by the new Common Token Manager, with reserved per-domain key ranges. sl_token_manager_manufacturing.h now splits on SL_TOKEN_MANAGER_FORMAT_LEGACY, and the Series-3 branch only defines tokens that were granted a KLV key — MFG_STRING, MFG_BOOTLOAD_AES_KEY, and MFG_EZSP_STORAGE didn't make the cut, while MFG_BOARD_NAME did. So MFG_STRING wasn't deprecated for any technical reason: it's just redundant with MFG_BOARD_NAME, and only one free-text identity string got a seat in the key budget.

The deprecation is enforced host-side, on all platforms — not just Series 3. In 2026.6.0's reference host stub (command-functions.h), sl_zigbee_ezsp_get_mfg_token() hard-codes the three deprecated token IDs to an expected length of 255 and discards the NCP's response entirely:

if (expectedTokenDataLength == 255) {
  (void)fetchInt8uPointer(tokenDataLength);   // skip whatever the NCP sent
  return 255;                                 // sentinel: deprecated/invalid
}

The app-framework helpers grew matching tombstones: sl_zigbee_af_get_mfg_string() (both af-soc.c and af-host.c) no longer reads the token and instead returns the literal string "(deprecated)". So even a Series-2 NCP that still physically has the data gets it thrown away by SiLabs' own host code.

Per-token rationale for the other two

• MFG_BOOTLOAD_AES_KEY — the legacy standalone-bootloader image-encryption key from the lockbits page. On Series 3 the Secure Engine owns secure-boot/key storage, so a plaintext AES key in flash is obsolete. This is the "removed legacy manufacturing security tokens" from release-note bug 1599783.
• MFG_EZSP_STORAGE — an 8-byte EM260-era scratch area for host data; dead weight.
• The legacy-only list also drops non-EZSP tokens on the same theme (lockbits words, serial number, Z-Wave set, thread join key, NVM3 crypto key, signed/secure bootloader keys — security material moving into the SE).

Implications for bellows (nothing to change now)

• getMfgToken (0x000B) itself is not removed in v19; only the three token values are tombstoned. MFG_BOARD_NAME still works normally.
• bellows builds its own frames rather than using SiLabs' host stub, so it will keep sending getMfgToken(MFG_STRING) and parsing the LVBytes reply. On Series-2 firmware the data likely still comes back (the NCP-side handler is precompiled, so its exact 2026.6.0 wire behavior isn't verifiable from source); on Series 3 expect empty/absent — get_board_info() already copes either way (strips \xFF/\x00, empty → None). And as the PR body notes, the XNCP XNCP_MFG_MANUF_NAME/XNCP_MFG_BOARD_NAME overrides bypass manufacturing tokens entirely.
• If Series-3 radios ever matter for board-info display, the natural follow-up is preferring MFG_BOARD_NAME (kept) over MFG_STRING (dropped). Worth knowing for diagnostics: firmware built on SiLabs' reference host path can now surface a literal "(deprecated)" string where a manufacturer name used to be.

[TheJulianJES]

Nice! The MFG_STRING stuff seems interesting 🤔

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.54%. Comparing base (afd55fb) to head (98f3044).

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #734   +/-   ##
=======================================
  Coverage   99.54%   99.54%           
=======================================
  Files          61       64    +3     
  Lines        4184     4203   +19     
=======================================
+ Hits         4165     4184   +19     
  Misses         19       19           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.