[sairex53]

Summary

A lazy registry cache manager can block inside Query while its import is waiting on registry I/O. The solver calls cache queries from scheduler.loop while holding the scheduler mutex, so one pending import can prevent unrelated builds from progressing.

Run root and dependency cache queries as scheduler requests when the cache manager is not ready. This lets the scheduler continue dispatching other edges while the import is pending. The lazy manager now supports context-aware waiting, and query inputs are snapshotted before the goroutine starts to avoid racing with scheduler updates to cache-key metadata.

This addresses the scheduler-wide stall described in #7275. The registry push writer hang is a separate failure mode; this change is complementary to the request-body cleanup in #7284.

Relates to #7275.

Testing

• go test ./solver -run '^TestSchedulerDispatchDoesNotBlockOnCacheQuery$' -count=1+�u����T passed (root and dependency query cases).
• go test -race ./solver -run '^TestSchedulerDispatchDoesNotBlockOnCacheQuery$' -count=1+�u����T passed.
• go test ./solver/llbsolver -count=1"��y��y� passed.
• go test -race ./solver/llbsolver -run '^TestLazyCacheManagerQueryContextCancellation$' -count=1 �w^~)�t passed.
• Remaining solver unit tests passed. TestJobsIntegration could not run because the host lacks the required registry binary.
• git diff --check"��y��y� passed.

[crazy-max]

I'm closing this PR because the volume and pattern of contributions from this account raise concerns about automated PR farming. As of October 20, GitHub shows 99 authored PRs, including 28 opened on October 19 and 20. Today's eight PRs were opened across eight repositories in roughly two hours and fifteen minutes. Examples include moby/moby#53986, seccomp/libseccomp#506, and iovisor/bcc#5578.

The stuck push-writer path reported in #7275 already has a proposed upstream fix in containerd/containerd#14360, which closes the request body when authorization fails so blocked writes can return and release their concurrency slots. Your PR proposes a separate scheduler change, so its necessity and scope need to be evaluated against that upstream fix rather than treated as established by the original report.

The activity pattern doesn't prove automation or establish that your change is incorrect, but it leaves me uncomfortable merging this contribution. If I've misread the situation, please reach out and explain how you're personally reviewing and validating these contributions. I'm open to correcting my judgment.