refactor(docker): optimize build architecture and security

[rmie]

The Problem

The original Dockerfile architecture attempted to graft Playwright into a Java (eclipse-temurin) base image. This forced the build to download and run playwright install-deps (which executes heavy apt-get commands for browser libraries) on every cache miss, drastically slowing down build times. Additionally, the build relied on insecure patterns (executing curl | bash for the Rust toolchain), created the appuser too late (risking UID conflicts), and improperly targeted the generic Spring Boot health endpoint.

This is a major refactor and I happily accept rejection because of "lacking tests". I'd willing to work on this and provide integration tests for the tools included in the image, covering aspects, like

• tool is executable
• output formats are still in the same format as assumed by mocks
• ..

But I'd need guidance for that.

The Solution

This PR entirely inverts the Docker architecture to use the official Playwright image as the runtime base, significantly improving build speeds, correctness, and security.

Key Architectural Changes:

• Inverted Base Image: Uses mcr.microsoft.com/playwright:v1.60.0-noble as the foundation, providing perfectly configured Chromium, Node, and shared libraries out of the box without requiring a slow install-deps step.
• Adoptium JDK: Installs temurin-21-jdk directly from the official Adoptium APT repository, retaining the exact same update speed and binaries as the eclipse-temurin Docker image.
• Secured Rust Installation: Eliminates the curl | bash pattern entirely. Rust is now extracted via a clean multi-stage COPY --from=rust:1-slim-bookworm, leveraging Docker Hub's image integrity while retaining perfect glibc backward compatibility.
• Preempted UID Conflicts: Relocated appuser creation to the very top of the runtime stage to claim UID/GID 1000 before any apt packages install, preventing fatal post-install script collisions.
• Corrected Healthcheck: Updated the HEALTHCHECK to use the /actuator/health/liveness probe, which is the correct Spring Boot endpoint for container orchestration restarts.

---

AI Usage Disclosure

This PR was heavily refactored using Google Antigravity.

• Level of Automation: AI completely rewrote the Dockerfile to implement the inverted base image architecture and wrote the Docker multi-stage COPY commands for the Rust toolchain.
• Human Involvement: The human developer acted as a strategic "sparring partner", driving the architectural requirements, and catching critical flaws (e.g., the risk of late appuser creation and the correct Spring Boot liveness endpoint). All code changes and builds were verified and explicitly approved by the human developer.

[rmie]

@tmseidel I spent some time this week working on integration tests, https://github.com/rmie/ai-git-bot/tree/feature/add-test-framework-integration-tests

Current State & Blockers

• Java: Tests are failing because the environment has a JRE but is missing a JDK.
• Ruby: gem install operations fail due to insufficient privileges for the APPUSER.
• Ctags: Encountered issues while trying to get tests working, resulting in a rollback.

"Tiny CI" & Security Trade-offs

The "tiny CI" concept offers a self-contained feedback loop, but it carries inherent architectural risks that need to be addressed:

• Arbitrary Code Execution (RCE): Running tests directly as APPUSER means every PR effectively has RCE within the container environment.
• Privilege Contention: Test execution requires elevated privileges (like installing gems or compiling code), conflicting with the restricted permissions required for the runtime APPUSER.

[tmseidel]

@rmie Great work so far. I'll take a deeper look on this in the next days, Scheduled this for 1.15.0