fix(spin-common): resolve codependency scheduling gaps for nested pre/post-processors and their ordering constraints

[deer]

Codependencies (@PreProcess/@PostProcess tasks) never get their own Instruction, so several kinds of scheduling information attached to them was being dropped on the floor. A codependency's own @From dependency was pulled into the Program without a real graph edge tying it to the owning task, letting the owner (and its inline codependency) get dispatched concurrently with, rather than after, that dependency. A @Before/@After annotation declared directly on a codependency's own Task class was silently ignored, since codependency resolution never went through DefaultInstruction's ordering-constraint pass. And a codependency that itself declared @PreProcess/@PostProcess had its own nested codependency dropped entirely, since resolution only ever looked one level deep.

DefaultInstruction now resolves codependencies transitively via addCodependenciesRecursively, discovering a nested pre/post-processor's own codependencies and preserving the correct execution order (a nested @PreProcess codependency's dependencies are added before it; a nested @PostProcess codependency's after). A new ultimateOwner helper walks a codependency's @PreProcess/@PostProcess chain up to the top-level Task that actually owns an Instruction, so @Before/@After declared anywhere in that chain gets folded into that owner's ordering-only dependencies instead of being lost. DefaultProgram's dependency-graph construction now also wires in edges for instruction.codependencies().flatMap(Invocable::dependencies), so a codependency's own data dependencies become real scheduling constraints rather than just being included somewhere in the Program with no ordering tie to the owner.

A known limitation is called out in the addCodependenciesRecursively Javadoc: a @PreProcess nested under a @PostProcess (or vice versa) isn't reordered relative to its target, since DefaultProgram#runTask executes all pre-processors as one flat group before the task and all post-processors as one flat group after.