Deprecate erroneous behavior in SP's `versioned_rot_boot_info` function

The initial PR for issue 2185 does not remove the all of the incorrect mappings of the MGS and RoT found in task/control-plane-agent/src/mgs_common.rs.
A simple correct mapping of versions is RoT version = (MGS version - 1) where MGS version > 0 .

The previous code mapped MGS 1 to a response constructed from data in a RoT V1 message instead of returning an error for the deprecated RoT version 0.

To ensure that RoT update, manufacturing processes, and any support procedures, continue to work across all prior supported update-capable versions, it is necessary to understand which, if any, combinations of MGS, SP, and RoT firmware may break if this old behavior is made consistent with the intended design, i.e. "fixed".

In general, this is the sort of exercise that we need to go through before deprecating any SP/RoT-related update code unless we choose to support old functions and data structures indefinitely.

In addition to the support burden of maintaining old interfaces, they expand the potential attack surface of the devices. So, it is desirable to trim the implementation where practical while maintaining a robust implementation.

Start in task/control-plane-agent/src/mgs_common.rs at the versioned_rot_boot_info function, then review the initial work referenced from issue 2185. Trace the supported MGS, SP, and RoT version combinations and identify which update, manufacturing, and support procedures depend on the old mapping. Done means the compatibility impact is understood and the deprecated behavior can be removed or consistently rejected without breaking prior supported update-capable versions.