Test iop validation during CI build on AOG-TaskController

[sujandumaru]

Attempt to add tools/iop_validator.cpp, a small standalone binary that loads an AOG_TC.iop file through AgIsoStack's own parser and reports anything wrong with the resulting object pool. It is registered as CTest cases and runs in the Linux CI job, so a malformed pool fails the build instead of finding that out on a VT.

Motivated by #67, where objects 10001–10004 carry an InputBoolean value of 24. A Kverneland Tellus rejects the pool; nothing in our build noticed.

What it checks

• Every object's own get_is_valid()
• Child references and the WorkingSet active mask actually resolve to objects in the pool (get_is_valid() skips unresolvable child IDs rather than rejecting them, and never looks at the active mask)
• Parser warnings are treated as failures — the parser repairs malformed attributes as it reads them, so an out-of-range OutputNumber format byte just becomes exponential and the log is the only evidence left
• Value ranges: InputBoolean is 0 or 1, list selection is within the item count, InputNumber / OutputMeter / OutputLinearBarGraph / OutputArchedBarGraph values sit inside their own min/max

Tests

tools/testdata/malformed_pool.iop is a copy of the pool with three defects injected on purpose, so the suite asserts more than "today's pool passes":

Test	Asserts
object_pool_attributes_in_range	the shipped resources/AOG_TC.iop is clean
malformed_pool_coerced_attribute	a silently-repaired attribute is caught
malformed_pool_dangling_reference	an active mask pointing at a missing object is caught
malformed_pool_value_out_of_range	an out-of-range InputBoolean is caught
malformed_pool_exit_status	the process actually exits nonzero

[sujandumaru]

One more thing: The test was added on Linux build only. If it passes linux, it should pass for Windows as well. I can definitely add it for Windows build as well if needed.

[gunicsba]

Maybe we can have this in a dedicated yml that could be easily added to other projects as well?

@copilot can you review and suggest?

[Copilot]

Maybe we can have this in a dedicated yml that could be easily added to other projects as well?

@copilot can you review and suggest?
...

Done — the IOP validation is now extracted into .github/workflows/validate-iop.yml as a reusable workflow_call workflow. It accepts two inputs (os and arch) so any other project can include it with just:

uses: AgOpenGPS-Official/AOG-TaskController/.github/workflows/validate-iop.yml@<ref>
with:
  os: ubuntu-latest
  arch: x86_64

build.yml now calls it three times (Linux x86_64, Linux aarch64, Windows) as separate jobs, so the pool is validated on all platforms. The main linux_build job has AOG_TC_VALIDATE_IOP=OFF so it focuses on building the distributable artifact without duplicating the validation work. Commit: ci: extract IOP validation into reusable validate-iop.yml workflow.

[gunicsba]

@sujandumaru what do you think about doing it like this?

[gunicsba]

Should make our build tougher. Especially if we keep extending this with future checks.

[sujandumaru]

@sujandumaru what do you think about doing it like this?

This looks a lot better. Thanks @gunicsba for the suggestion.