Fix ScanningRecipe accumulator loss in preconditioned DeclarativeRecipes across RecipeRunCycles

[pstreef]

Problem

When a DeclarativeRecipe has preconditions (e.g. Singleton), its getRecipeList() wraps sub-recipes as BellwetherDecoratedScanningRecipe. These wrappers are new ScanningRecipe instances created on every call, each with a new UUID-based accumulator key.

RecipeRunCycle creates a RecipeStack which caches getRecipeList() results in an IdentityHashMap — so within a single cycle, the wrappers are stable. But when a new RecipeRunCycle is created (as happens when the Moderne platform yields on large repositories), the fresh RecipeStack calls getRecipeList() again, producing new wrappers with different UUIDs.

The accumulator data stored on the rootCursor under the old UUID becomes unreachable. The new wrapper creates a fresh empty accumulator, and all scan data collected in previous batches is lost. The edit phase then finds nothing to change.

The wrapping cascades through the entire recipe tree — BellwetherDecoratedRecipe.getRecipeList() and BellwetherDecoratedScanningRecipe.getRecipeList() both call decorateWithPreconditionBellwether() on their delegate's children. So any ScanningRecipe at any depth under a preconditioned parent is affected.

Solution

Override getAccumulator() in BellwetherDecoratedScanningRecipe to delegate to the wrapped recipe's accumulator. This uses the delegate's stable UUID (assigned once at construction) instead of the wrapper's ephemeral one, so accumulators survive across RecipeRunCycle boundaries regardless of how many times the wrapper is recreated.