fix(build): resolve content anchors concurrently in parallel builds

[alexey-igrychev]

Summary

Everything werf does before the first build worker starts — a content-based digest per image, then a storage lookup per digest — walked the image graph one image at a time. On a Deckhouse configuration with 1122 content anchors that phase took 327 s of the cold run, dominated by two repository worktree preparations that waited for each other, and 61 s of a warm one. Both passes now run with the same worker limit the build itself uses.

What

• With --parallel, anchor digests are computed over the dependency graph with at most --parallel-tasks-limit images at a time; an image is handed out only after every image it depends on has a digest, so the inputs of a digest are unchanged. VERIFIED: the digests of a parallel run equal those of a sequential run on the same graph.
• With --parallel, the storage lookup for the resolved anchors runs with the same limit, each task with its own stages iterator and its own log buffer; per-image logs are still replayed with their image.
• Without --parallel, or with a single image, both passes walk the graph in order exactly as before.
• Log blocks of the prepass are emitted per image by the existing parallel printer, so they no longer appear in graph order when the build is parallel; they are not interleaved.
• Nothing about what is built changes: same digests, same reuse decisions, same set of skipped images.

Why

The two passes are pure preparation: they read git worktrees and ask the storage what already exists, both dominated by waiting, and the build that follows already runs images concurrently under the same limit. Keeping them sequential meant the slowest repository in the graph blocked every unrelated lookup behind it. The dependency graph, not a flat list, drives the digest pass because a digest includes the digests of the image's dependencies; the scheduler that the parallel build already uses provides exactly that ordering.

[alexey-igrychev]

Verification

• Mutation: replacing the graph scheduler with a flat parallel walk -> "calculates the same digests whether or not the build is parallel" failed, because the dependent image was handed out while its dependency was still being computed and ended up without a digest; ignoring --parallel in the worker count -> "bounds concurrency by the build parallelism" failed; sharing one prepass copy across the lookup tasks instead of a copy per task -> the existing "Content anchor cache prepass" specs failed.
• task test:unit paths="./pkg/build/..." -- -race is clean. It was not at first: the test storage manager stub counted its lookups without a lock, which the concurrent lookup pass exposed; the stub now locks.

Review focus

• resolveContentAnchor can copy an image from a secondary stages storage on a miss; this makes those copies concurrent. The storage manager is already used concurrently by build workers, but this is the path to look at.
• Pre-existing, not touched here: with --loglevel=debug, parallel.DoTasksDynamic logs to the shared logger while the printer goroutine renders task output through the same logger, which the race detector flags. It affects the parallel build path equally.

[alexey-igrychev]

Upstream twin werf#7931 is green. Measured together with #367 and #368 on the Deckhouse configuration: cold run to the first build worker 13:09 -> 8:22, stage determination 7:24 -> 2:56, all 1122 anchor digests identical to the unmodified binary.