Bump AgIsoStack++ to upstream main (includes #718)

[gunicsba]

Summary

Bumps AgIsoStack++ from c0e1ebb (19 Sep) to upstream main fbf5236 (14 Oct), the merge of Open-Agriculture/AgIsoStack-plus-plus#718. 31 commits, upstream repository, no fork and no local patches.

What this gets us

Address claim / partner handling (Open-Agriculture/AgIsoStack-plus-plus#718):

• A control function that was pruned and then claims its address again now gets credit for that claim. Before, it went back into the table already eligible for pruning and was dropped again at the next address claim request. On a bus with periodic roll-calls this becomes an endless offline/online cycle. While a CF is out of the table its broadcasts are silently dropped, so a partner bound to it (our VT, an implement) keeps going deaf.
• The roll-call no longer credits whichever inactive CF on the channel happens to come first.
• This is not the John Deere 6R fix (John Deere 6R #97). That one is a partner bound inside the 755 ms window and replacing an external CF (update_new_partners(), Keep a new partner's address claim credit when it replaces a control function Open-Agriculture/AgIsoStack-plus-plus#724), which #718 does not touch.

VT client (our VT UI):

• Fix VT client size calculation for Extended Input Attributes objects Open-Agriculture/AgIsoStack-plus-plus#782: correct sizing of Extended Input Attributes objects when autoscaling a pool. Autoscale now fails instead of hanging forever on an object it cannot size. Our pool has no Extended Input Attributes objects, and a walk of resources/AOG_TC.iop with the new sizer sizes all 88 objects and ends exactly at the end of the pool, so autoscaling is unaffected.
• Fix VT client timeout while object pool parsing is in progress Open-Agriculture/AgIsoStack-plus-plus#774: the client no longer fails in WaitForEndOfObjectPoolResponse / WaitForLoadVersionResponse when the VT takes more than 3 s to parse the pool. On VT version 3+, it keeps waiting while the VT status message reports "parsing", as ISO 11783-6 C.2.2 requires. Before, a slow terminal made us drop the connection and start over.
• Fix: VT client can get permanently stuck waiting for VT Status message Open-Agriculture/AgIsoStack-plus-plus#719: WaitForPartnerVTStatusMessage now times out and retries like every other wait state, instead of waiting forever when the VT stops broadcasting its status.
• Handle the Extended Version commands in the VT server and client Open-Agriculture/AgIsoStack-plus-plus#768: Extended Version commands now work. See the behaviour change below.

CAN hardware:

• Close the CAN driver when the hardware interface stops Open-Agriculture/AgIsoStack-plus-plus#722: CANHardwareInterface::stop() now closes the driver, so the adapter is released on exit.
• Report SocketCAN open failures through start() and get_last_error() Open-Agriculture/AgIsoStack-plus-plus#747 / Report why Windows CAN plugins failed to open through get_last_error Open-Agriculture/AgIsoStack-plus-plus#759: start() returns false when a channel fails to open, and the Windows plugins (PCAN-Basic, TouCAN, SYS TEC, InnoMaker) report why through get_last_error(). We now add that reason to the "Failed to start CAN hardware interface." log line.

The rest of the bump is VT server, TC client, ISOXML export, tutorial and example changes. They don't reach code we use.

Changes in this repo

• CMakeLists.txt: new GIT_TAG.
• Application::stop() now checks CANHardwareInterface::is_running() instead of the removed canHardwareStarted flag. Since Report SocketCAN open failures through start() and get_last_error() Open-Agriculture/AgIsoStack-plus-plus#747, start() can return false and still have started the update thread and set started. With the old flag, the failed-initialize path from Decouple logging from the main loop to stop it stalling ISOBUS transmit #79 would skip stop() and leave that thread running.
• The CAN start failure log line includes canDriver->get_last_error() when it is not empty.

Behaviour change to watch on hardware

Our VT pool version label is hash_object_pool_to_version() output: a 64-bit hash in hex, usually 16 characters. Until now the client sent only its first 7 characters with (Store/Load) Version. After Open-Agriculture/AgIsoStack-plus-plus#768, on a VT version 5 or later with a label longer than 7 characters, the client uses the Extended Version commands with the full label. Expect one full pool upload on VT5+ terminals the first time, because the old 7-character version no longer matches. Terminals at VT version 4 or below behave as before. If a VT5+ terminal turns out to handle Extended Version badly, cutting the label to 7 characters on our side restores the old behaviour.

Test plan

• Windows Release build (Visual Studio 2026) and ctest pass, from a fresh fetch of fbf5236
• resources/AOG_TC.iop walked with the new get_number_bytes_in_object(): 88 objects, no unsized object, ends at the pool end
• CI build on Windows and Linux
• Start with no adapter or a wrong channel: the log shows the driver's reason and the app exits cleanly
• Connect to a VT (ideally both a VT4 and a VT5+ terminal): the pool loads, and on reconnect the stored version loads without a second upload

🤖 Generated with Claude Code

[gunicsba]

No adapter / wrong channel test:

Logging to file: C:\Users\GunicsBa\AppData\Roaming\AOG-TaskController\logs/AOG-TaskController_2026-10-14_8-36.log
C:\Program Files\AOG-TaskController\bin\AOG-TaskController.exe --can_adapter=PEAK-PCAN --can_channel=2 --log_level=debug --log2file
AOG-TC version: v554b332
[08:36:46.946] [Critical][PCAN]: Unable to open PCAN channel 0x52, The value of a handle (PCAN-Channel, PCAN-Hardware, PCAN-Net, PCAN-Client) is invalid (error 0x1400). Is the PEAK adapter plugged in?
[08:36:46.946] [Error][HardwareInterface] Channel 0 failed to start, its driver is not valid after opening.
[08:36:46.946] Failed to start CAN hardware interface. Unable to open PCAN channel 0x52, The value of a handle (PCAN-Channel, PCAN-Hardware, PCAN-Net, PCAN-Client) is invalid (error 0x1400). Is the PEAK adapter plugged in?
[08:36:46.946] Failed to initialize application...