`host-sp-comms` inventory probably should have a separate error code for bad device _contents_

IPCC inventory lookups return the following error codes:
https://github.com/oxidecomputer/hubris/blob/e744ccf5d11b68b9e6212db4846b75f2c71468d6/lib/host-sp-messages/src/lib.rs#L261-L271

Presently, DeviceFailed is what the SP will return when reading VPD from a device if the device returns an error, or if the data read from the device is malformed or corrupted. For example:

https://github.com/oxidecomputer/hubris/blob/e744ccf5d11b68b9e6212db4846b75f2c71468d6/task/host-sp-comms/src/inventory/compute_sled_common.rs#L133-L136

While testing #2229, @citrus-it and I saw that the host software will map the DeviceFailed result (code 3) to EIO, so it gets presented as an "I/O error":

gimlet-sn06 # ipcc inventory 0x48
metadata:
    version: 0x0
    entries: 0x49
J180/ID (72) -- Result: 3 [I/O error]

This doesn't feel quite right to me. I think we should introduce a new error code to represent "we read something from the device, but it didn't parse, had an invalid checksum, or an expected TLV-c tag was not present". Of course, adding new messages to the protocol will require coordination with the host side.

Read the inventory error-code definitions in lib/host-sp-messages/src/lib.rs and the VPD handling in task/host-sp-comms/src/inventory/compute_sled_common.rs. Trace how malformed or invalid device contents become DeviceFailed, then determine the required host-side coordination for a distinct protocol error code. Done means the protocol and host mapping clearly distinguish device errors from invalid contents.