[Java]feat: Run auto-instrumentation init container as non-root user

[Miqueasher]

Problem

Customers enforcing runAsNonRoot: true via Pod Security Standards cannot use ADOT auto-instrumentation. Kubernetes checks the image metadata for a USER directive, finds none (defaults to UID 0 / root), and rejects the pod with:
Error: container has runAsNonRoot and image will run as root

Summary

Enables customers using the Kubernetes Restricted Pod Security Standard to use ADOT auto-instrumentation
Without this change, customers enforcing runAsNonRoot: true at the namespace or pod level cannot use ADOT auto-instrumentation because Kubernetes rejects the init container with:
container has runAsNonRoot and image will run as root

Follows the upstream OTel Operator fix (open-telemetry/opentelemetry-operator#2272)

Changes

Add USER 65534:65534 to the auto-instrumentation Dockerfile so the init container runs as non-root by default

Testing

Validated on EKS cluster (us-east-1, EKS v1.34.6) with CW Observability add-on v5.3.1

For more in-depth analysis please see Test Results

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mxiamxia]

Could you confirm the behavior when USER 65534:65534 can copy the ADOT jar file during initContainer phase without permission issue? My understanding is that K8s emptyDir volumes default to root:root 0755, so the init container may not be able to write javaagent.jar to the shared volume which would affect existing customers. I'd like we can confirm this. Thanks