Add "Bale windrows" AI job

[BrewingCoder]

Adds a new Courseplay AI job, Bale windrows, that generates a course following the actual straw/hay/grass windrows lying on the field, so an attached baler drives only where the product is instead of a generic up/down pattern that over-covers empty ground.

Closes#1293

What it does

• Baler-gated: the job is only offered when a baler is attached (getCanStartCpBaleWindrows → AIUtil.hasChildVehicleWithSpecialization(Baler)).
• On Generate, it detects the field and reads the windrows off the ground via DensityMapHeightUtil, then builds a fieldwork course whose work rows trace them.
• Windrows are read dynamically as density ridges — each row is found at its own angle/curve, nothing globally imposed (no fixed row angle or spacing).
• Headland windrows (straw that wraps the boundary) are driven first, then the interior rows are swept edge-to-edge.
• Rows are WORK waypoints, so CP lowers/raises the baler and generates the turns itself; a short in-field overrun past each row end keeps the baler down across the whole windrow.

Notes for review

• The windrow sweep runs once, on the Generate action only — never in the boundary-detection/validate loop (which fires every frame).
• Baled-over residue is filtered by a straw-level cutoff so a baled field reads as empty.
• Phantom headland rings from rows that merely run parallel to an edge are rejected by a boundary-wrap coverage test (offset the boundary inward by the ring distance; a real ring lands on straw all the way around).
• CpObject change: propagate the Giants base constructor down the whole inheritance chain so a grandchild job (this one) initializes its AIJob base.

Still iterating on in-field tuning (row-end coverage overrun, residue cutoff), but the job is functional end-to-end. Feedback on approach welcome.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KhF4kNA6TWw3EJ8hy99SHM

[pvaiko]

This is a very cool feature.

However, it shows all the problems of AI generated code, for instance it does not reuse the existing code (such as the headland generation), it pollutes the CourseGeneratorInterface, which supposed to a thin adapter layer only, with business logic, etc.

Sure, this could be improved by adding an AGENTS.md, several skills, but that needs time as well as a dedicated, skilled, motivated person.

And even then, it is questionable when the code quality (which isn't perfect now of course, but is ok) will deteriorate to the point where no one, including Claude will be able to fix small bugs.

Elsewhere I follow the policy that vibe coding is only allowed for non-production code, such as development or monitoring tools or utilities. In those cases only, code review is not needed, no human needs to understand the code, we ignore code quality and improvements and fixes are done by AI (again, how long this works depends on many factors, but every change will likely deteriorate code quality).

Every production code though must go through a strict code review and a human must understand the code. This however can be very time consuming, for example, WindrowDetector.lua is way too big and complicated compared to the time and motivation I have.

We could also just give up and declare that some parts (must be very well defined parts) of CP are AI coded, but then comes the question of maintenance. Who is going to fix a bug in WindrowDetector? The context likely would be lost long ago (unless some agent or skill file checked in with the code), are you @BrewingCoder ready to support this for years?

We'll think about how CP wants the handle AI code.