What changed

No user-facing behavior change.

Groundwork for #173 (engraving message). When a debug recording is active, capod now dumps the structured contents of the AirPods info packet (the one sent right after a connection is established) into the log file. This includes non-ASCII bytes, so emoji or non-Latin engravings would be visible. The intent is that testers with engraved AirPods can attach a debug log so the protocol can be analyzed for where (or whether) Apple's engraving message lives.

Technical Context

• Why diagnostic-only: no public reverse-engineering of the engraving exists (checked librepods, MagicPodsCore-style references, capod itself), and no engraved device is available for testing. Most likely the engraving lives only in iCloud and is looked up by serial — but we cannot confirm without a real capture. Shipping a UI field would be premature; a logger lets us crowdsource the discovery.
• Why a separate parser instead of extending parseNullTerminatedStrings: the production parser is ASCII-only (0x20..0x7E) and would silently drop emoji or non-Latin engravings. The diagnostic helper uses strict UTF-8 with a hex fallback so any encoding survives. The production decode path is intentionally untouched — no widening of protocol assumptions for a debug-only purpose.
• Why unconditional on 0x1D: the dump fires regardless of whether decodeDeviceInfo succeeds — an engraving-shaped packet that the strict decoder rejects still needs to be captured.
• Privacy: the dump contains device serials, left/right bud serials, manufacturing IDs and an encrypted blob. Anyone sharing a log file should redact serials before pasting publicly.
• Verified on hardware: tested on a real AirPods Pro 2 USB-C — emits 13 segments with the expected slot labels (name, modelNumber, manufacturer, serialNumber, firmwareVersion, then unknown). The encrypted blob lands as a 44-byte non-UTF-8 segment because there is no NUL between it and the following manufacturing-date string on the wire.
• Tests: a real-capture happy path, a synthetic emoji payload (regression for the ASCII-only drop), and a malformed-short payload (regression for "must not gate dump on decodeDeviceInfo success").

Refs #173.