ci: use native arm64 runners for multi-arch Docker builds

[GenerQAQ]

Why we need this PR?

Multi-arch Docker builds (amd64 + arm64) use QEMU emulation on x86 runners, making arm64 builds extremely slow. The UI (Next.js) release was stuck for 40+ minutes because npm ci + next build under QEMU is ~5-10x slower than native. This affects all components using the reusable Docker release workflow.

Describe your solution

Replace QEMU-emulated builds with native arm64 runners (ubuntu-24.04-arm), building each platform in parallel on its native architecture, then merging into a multi-arch manifest.

_reusable-docker-release.yaml:

• Split single build-and-push job into build (matrix) + merge jobs
• build matrix: amd64 on ubuntu-latest, arm64 on ubuntu-24.04-arm — both run in parallel
• Each pushes a platform-specific tag (e.g., sha-<sha>-amd64)
• merge job uses docker buildx imagetools create to combine into multi-arch manifest
• Cache scopes split per platform (image-amd64 / image-arm64) to avoid cross-arch pollution
• Removed QEMU setup (no longer needed)
• Added optional file input for custom Dockerfile paths

admin-release.yaml:

• Refactored from standalone 71-line workflow to reuse _reusable-docker-release.yaml (21 lines)
• Passes file: ./src/server/api/go/Dockerfile.admin via the new input

Implementation Tasks

• Rewrite _reusable-docker-release.yaml with matrix strategy + native runners
• Add file input to reusable workflow for custom Dockerfile paths
• Refactor admin-release.yaml to use the reusable workflow
• Validate with actionlint

Impact Areas

• Client SDK (Python)
• Client SDK (TypeScript)
• Core Service
• API Server
• Dashboard
• CLI Tool
• Documentation
• Other: CI/CD workflows (all Docker release pipelines: UI, API, Core, Admin)

Checklist

• Open your pull request against the dev branch.
• All tests pass in available continuous integration systems (e.g., GitHub Actions).
• Tests are added or modified as needed to cover code changes.