probe-rs on LPC-Link2 v1.0.7: blocker #4 — SerialNumber + remaining DAP_Info fallbacks (#930 follow-up)

[zackees]

Split-out of #930 (which was closed once the first three DAP_Info fallbacks landed in FastLED/probe-rs#1).

Scope

Continue the "silent DAP_Info sub-command → spec-safe fallback" pattern for any remaining queries that the LPC-Link2 CMSIS-DAP v1.0.7 firmware also drops:

• DAP_Info(SerialNumber = 0x03) — likely same behavior; probe-rs currently propagates the timeout up through list.rs and blanks the identifier field. Verify.
• DAP_Info(Vendor = 0x01), DAP_Info(Product = 0x02) — probably return, but the LPC-Link2 v1.0.7 may drop these too. Verify.
• DAP_Info(FirmwareVersion = 0x04) — same treatment; a fallback of the literal string `"unknown"` is the natural default.
• Any other DAP_Info sub-command that surfaces in list-flow / probe-open traces under RUST_LOG=probe_rs::probe::cmsisdap=trace against the attached LPC845-BRK.

Fix pattern

Same as FastLED/probe-rs#1 — catch `SendError::Timeout`, log warn!, return the spec-safe default rather than propagating the error.

Acceptance

• Full `probe-rs info --chip LPC845M301JBD48 --probe 1fc9:0132` invocation reaches the SWD attach step (does not fail during any DAP_Info sub-command).
• COM10 stays openable across all attempts.
• Every fallback taken logs its own warn! line so the mode-of-operation is visible.

Related

• probe-rs on LPC-Link2 CMSIS-DAP v1.0.7: series of upstream quirks to patch through #930 (parent umbrella, now closed)
• FastLED/probe-rs#1 (blockers 1-3 landing PR)
• fbuild deploy: own nxplpc/LPC8xx flash end-to-end (FastLED is removing its direct pyocd path) #921 (parent tracking issue for LPC845-BRK end-to-end deploy)