## Summary

The versioned `v1.83.14-stable` Docker image publishes a `linux/arm64` manifest entry whose OCI config declares `architecture: arm64`, but the image contents are actually **amd64/x86_64 binaries**. Pulling with `--platform linux/arm64` succeeds, yet the container runs as `x86_64` and core binaries such as `/usr/bin/python3.13` and `/bin/sh` are ELF `e_machine 0x3e` (amd64), not `0xb7` (aarch64).

This breaks any arm64 deployment that copies runtime artifacts from the image (e.g. multi-stage Docker builds on aarch64 hosts).

## Affected images

Both registries expose the same broken arm64 variant:

- `docker.litellm.ai/berriai/litellm:v1.83.14-stable` - `ghcr.io/berriai/litellm:v1.83.14-stable`

## Steps to reproduce

On a native **aarch64** host (or any environment where amd64 emulation is not masking the problem):

```bash # Pull the arm64 variant explicitly docker pull --platform linux/arm64 ghcr.io/berriai/litellm:v1.83.14-stable

# Inspect runtime architecture and ELF machine type of bundled Python docker run --rm --platform linux/arm64 --entrypoint sh \ ghcr.io/berriai/litellm:v1.83.14-stable -c ' echo "uname -m: $(uname -m)" echo "python3.13 e_machine: $…