IPCC sensor list is incomplete

...you can help by expanding it.

https://github.com/oxidecomputer/hubris/pull/2108 was recently merged (edit: and https://github.com/oxidecomputer/hubris/pull/2578 is now open), which made three new temperature sensors available on gimlet (and cosmo) from the rails controlled by ISL68224 devices. These new sensors showed up automatically in humility-based querying.

However, for IPCC-based querying, e.g. over host-sp-comms, @rmustacc pointed out that:

• Sensor data retrieval is based on SensorId
• These mappings are on a per device basis
• These mappings are handled manually

An example of this can be found here, where we match on a magic number:

github.com/oxidecomputer/hubris/blob/b931e44d5e340a5dfda2c02153507db1bfa38ed1/task/host-sp-comms/src/bsp/cosmo_ab.rs#L182.

Also worth noting that InventoryData::Isl68224 doesn't include temp_sensor, like InventoryData::Bmr491 does.

I'm not currently sure where the authoritative definition of SensorId is, whether it is just these match statements in the BSP, or if there is another place where this match statement is following. However, the code says:

/// Indexes are assigned arbitrarily and may change freely with SP
/// revisions.

Which is even more confusing to me, personally.

At a minimum, we should probably "plumb through" these new temperature sensors, and potentially add temperature sensors to InventoryData::Isl68224's fields.

Longer term, it might be better to use a different/stable identifier for this querying, perhaps by refdes or rail name. I'm unsure of the bigger picture here, so open to suggestions.

CC @rmustacc, @hawkw

Start in task/host-sp-comms/src/bsp/cosmo_ab.rs at the SensorId match statements, then inspect InventoryData::Isl68224 and compare it with InventoryData::Bmr491. Trace how the per-device mappings serve IPCC querying over host-sp-comms. Done means the new temperature sensors are exposed for gimlet and cosmo, with any required inventory fields updated.