Speed up repeated runtime image builds

[IOHelpMe]

Summary

• prepare Go modules and the pinned oapi-codegen tool in a dependency-only Docker layer
• persist the Go module and compiler caches across source-invalidated BuildKit builds
• build the module outside GOPATH in /src and copy both runtime binaries from there
• validate the cache-sensitive Dockerfile ordering in pull-request CI

Why

The previous Dockerfile copied the complete repository before dependency setup and built under /go. Any source or version change therefore invalidated dependency/tool work and forced unchanged Go packages to be rebuilt during every local runtime-image refresh.

This matters in the normal Druid workflow because make k3d-build-pull-image must rebuild druid:local before importing it into k3d.

No build work is skipped

This change does not add a conditional or bypass any required build target. Every source-invalidated image build still executes the complete make build target, including all three OpenAPI generation commands and compilation of both druid and druid-coldstarter. Only unchanged module downloads, tool installation, and compiler artifacts are reused.

Measured impact

Measurements were taken on the same Windows/WSL/Docker Desktop development machine:

Scenario	Before	After	Saving
Source-invalidated runtime-image rebuild	51.7 s	11.4 s	40.3 s (79.6%)
Cold optimized build	-	50.5 s	Practically unchanged from the 51.7 s baseline

The cold result demonstrates that the optimization does not hide or remove build work. The benefit appears on the repeated source rebuilds used by local development.

Validation

• bash scripts/docker-build-cache.test.sh
• go test ./...
• real Docker build from committed revision 29a8ad0
• build log confirmed all three OpenAPI generator invocations and both Go compilation commands
• resulting image contained executable /usr/bin/druid and /usr/bin/druid-coldstarter
• druid version returned codex-perf-pr-29a8ad0

[druid-infra]

Error: This repo is not allowlisted for Atlantis.

[IOHelpMe]

CI-Nachbesserung e8d09d9: Der erste Run scheiterte ausschließlich im prerelease-Job, weil Fork-PR-Tokens nur contents:read erhalten und das Erstellen von Release pr-93 deshalb mit 403 abgewiesen wurde. Unit-, Integrations-, API- und Build-Checks inklusive Cache-Regression waren grün. Der bereits in PR #92 bewährte Fork-Guard überspringt nur prerelease und den davon abhängigen Docker-Publish in externen Forks; interne PRs bleiben unverändert. Lokal grün: YAML-Parse, Strukturassertion, git diff --check und scripts/docker-build-cache.test.sh. Der Push hat einen neuen GitHub-Run ausgelöst.

[IOHelpMe]

Finaler Status für e8d09d9: unit-tests, integration-tests, validate-api und build sind grün. prerelease und der davon abhängige docker-builds-Job sind für diesen externen Fork erwartungsgemäß und sicher SKIPPED; genau das verhindert den vorherigen 403, ohne interne PRs oder den eigentlichen Build zu verkürzen.