Frontend CI: Roll Back Multi-Platform Docker Builds to Single-Platform

This change reverts a recent update to the frontend's deployment pipeline that had switched container image builds to multi-platform (Intel and ARM) using Docker Buildx. The pipeline now returns to its previous, proven single-platform build process, restoring deployment stability for the QA environment.

A prior change reconfigured the frontend's container build to produce images for two CPU architectures (linux/amd64 and linux/arm64) via a dedicated Buildx builder. Reverting it indicates the multi-architecture approach introduced problems in the build/deploy pipeline (e.g., build failures, longer build times, or push issues), so the team rolled back to the known-good configuration to keep deployments reliable.

No user-facing or functional changes to the application itself. The impact is operational: the frontend container image is once again built for a single architecture and pushed to the registry using the original, stable steps. This unblocks and stabilizes the QA deployment pipeline. End users see no difference in the app.

• Single file changed: .github/workflows/docker-ecr.yml (CI/CD GitHub Actions workflow), +2 / -9 lines.
• Removes the "Create and use buildx builder" step that set up a multiarch-builder (docker-container driver).
• Reverts the image build from docker buildx build --platform linux/amd64,linux/arm64 ... --push back to a plain docker build -t ... followed by a separate docker push.
• All --build-arg values (NEXT_PUBLIC_API_URL, SOCKET_URL, AUTH/SSO URLs, STRAPI config, etc.) are preserved unchanged.
• Pure revert of commit 92e7ce3; no application source code touched.

Low risk; this is a revert to a previously validated build configuration with no application code changes. The only consideration is that the produced image is now single-architecture only (linux/amd64). Mitigation: confirm the QA deployment target runs on a matching architecture, and verify the next build successfully produces and pushes an image before relying on it.

• Trigger the frontend CI workflow and confirm the image builds and pushes to ECR without errors.
• Verify the deployed QA frontend starts and runs normally on its host (correct architecture).
• Smoke-test core app flows (login/SSO, basic navigation) to confirm the rebuilt image is healthy.
• Confirm build-time environment variables (API/SOCKET/AUTH/STRAPI URLs) are correctly baked into the image.