worker: preflight check that sandbox images are accessible

[arpitjain099]

What this does

Adds a startup preflight check to the analysis worker that confirms every configured sandbox container image is accessible before the worker begins consuming pubsub messages.

Today the worker only discovers that a sandbox image is missing or misconfigured once it tries to pull/run it while handling a message. By then a message has already been received, and a failure there can lead to messages being acked errantly. Checking up front lets the worker fail loudly at startup instead.

Approach

Following the suggestion in the issue, the check uses go-containerregistry's remote.Get to resolve each image's manifest. This confirms the image is reachable and the worker is authenticated for it, without pulling the image.

The images checked are the static and dynamic analysis sandbox images (StaticSandboxOptions / DynamicSandboxOptions), combined with the configured image tag (OSSF_SANDBOX_IMAGE_TAG, defaulting to latest). SandboxImageURLs(tag) is the single source of truth for that set.

The check is wired into cmd/worker main, after network init and before messageLoop. If any image cannot be accessed, the worker logs an error naming the offending image(s) and exits non-zero. The check is skipped when OSSF_SANDBOX_NOPULL is set, since in that mode the worker deliberately relies on images that are already present locally rather than a registry.

Testing

The registry resolution is injected behind an ImageChecker func so the aggregation logic is unit tested without network access:

• one configured image missing produces an error that names that image and not the available one,
• multiple missing images are all named,
• the all-present case returns nil,
• SandboxImageURLs returns both images and defaults an empty tag to latest.

go test ./internal/worker/, gofmt -l, and go vet are clean for the affected packages.

Fixes #346