Decode End of Object Pool response error bits in the log

[Arjan-Woltjer]

Summary

The Object Pool Error Codes byte in the End of Object Pool Response message (ISO 11783-6:2004 section C.2.5) was only ever logged as a raw integer (Pool error bitmask value N), leaving every rejection to be manually looked up against the standard. This adds per-bit decoding into the existing LOG_ERROR call:

• bit 0: method or attribute not supported by the VT
• bit 1: unknown object reference (missing object)
• bit 2: any other error
• bit 3: suppressed unless it's the only bit set -- the standard states a VT should delete the object pool from volatile memory on any error at all, so this bit rides along with essentially every rejection and isn't itself diagnostic. Surfacing it only when it's alone (which would be unusual) avoids drowning the real signal in boilerplate.

Logging-only change; no control flow affected.

Motivation

Hit this directly on real hardware: a Fendt Universal Terminal rejected an object pool with Pool error bitmask value 9, which required a manual trip to the ISO 11783-6 standard text to decode as bit 0 + bit 3 ("method/attribute not supported" + boilerplate). The reference VirtualTerminalServer in this ecosystem also hardcodes this byte to 0 on send (unimplemented), so there's no other place in the codebase that documents this bit layout today.

Test plan

• Verified the decode logic against the real rejection above (bitmask 9 -> bit 0 + bit 3, matches the standard's table).
• Build-verified against a real ISOBUS project targeting Teensy 4.1.
• Open question for maintainers: would you prefer named constants/an enum for these bits (mirroring TaskControllerClient::ServerOptions's style) over inline bit literals? Happy to rework if so.

[Arjan-Woltjer]

Checked against ISO 11783-6 2004, if later versions of this document are available, it is worth checking if the reserved bits 4-7 now have any meaning (in section C.2.5 of the 2004 document they are listed as reserved and transmitted as 0).