fix(piraeus-server): Use TARGETARCH for losetup-container download

[lexfrei]

Summary

Use TARGETARCH instead of $(uname -m) for downloading losetup-container binary, consistent with how k8s-await-election and kubectl are already downloaded in the same Dockerfile.

Motivation

The Dockerfile already uses ${TARGETARCH} for two other downloads:

• Line 69: k8s-await-election-...-linux-${TARGETARCH}.tar.gz
• Line 76: .../bin/linux/${TARGETARCH}/kubectl

Only losetup-container uses $(uname -m). This change aligns all architecture-dependent downloads to use the same explicit mechanism.

Changes

# Before
RUN wget "...losetup-container-$(uname -m)-unknown-linux-gnu.tar.gz"

# After
RUN ARCH=$(case ${TARGETARCH} in amd64) echo x86_64;; arm64) echo aarch64;; *) echo ${TARGETARCH};; esac) && \
    wget "...losetup-container-${ARCH}-unknown-linux-gnu.tar.gz"

[WanzenBug]

This returns the build host architecture, not the target architecture.

Wrong. The command gets executed in a linux/arm64 container. Which means that (thanks to qemu-user emulation), this returns the expected aarch64.

@lexfrei Is there actually an issue or did you just put your AI to work fixing issues it "found", that are not actually there?

[lexfrei]

You're right that uname -m works correctly under QEMU emulation — I reviewed the code change but didn't properly review the AI-generated PR description, which incorrectly claims it returns the build host architecture. Apologies for that.

That said, the code change itself is still worthwhile for consistency: k8s-await-election (line 69) and kubectl (line 76) in the same Dockerfile already use ${TARGETARCH} for downloads. Only losetup-container uses uname -m. Aligning all three to use TARGETARCH makes the Dockerfile consistent and explicit.

I've updated the PR description to reflect the actual motivation.