Add Riva Speech Server as an ARM64 Docker image

[openminddev]

This pull request introduces support for running the Riva Speech Server as an ARM64 Docker image, making it easier to deploy speech services on ARM-based hardware (such as NVIDIA Jetson devices). The main changes include a new Dockerfile for building the ARM64 image, a new GitHub Actions workflow for building and releasing the image, updates to the Docker Compose configuration to add the new service, and a startup script to orchestrate service startup.

ARM64 Riva Speech Server Support:

• Added a new Dockerfile docker/Dockerfile.riva to build an ARM64-based Riva Speech Server image, installing necessary dependencies and copying application code and scripts.
• Introduced a startup script docker/scripts/start_riva.sh to launch the Riva server and associated Python services in the container.

CI/CD and Deployment:

• Created a new GitHub Actions workflow .github/workflows/release.yml to automate building, tagging, and publishing the ARM64 Docker image to Docker Hub, including manifest creation for multi-arch support.
• Updated docker/docker-compose.yml to add a riva_speech service that uses the new image, exposes relevant ports, sets environment variables, mounts model data, and configures GPU and device access.

In general, the fix is to add an explicit permissions block to the workflow or to each job, granting only the minimal scopes required. Since this workflow only checks out code and interacts with Docker Hub and does not appear to need write access to the GitHub repository, a safe and minimal choice is contents: read at the workflow level so it applies to both jobs.

Concretely, in .github/workflows/release.yml, add a top-level permissions: section near the top of the file (for example after the on: block) with contents: read. This will limit the GITHUB_TOKEN for all jobs in this workflow to read-only repository contents while preserving current functionality. No imports or additional methods are necessary, as this is purely a YAML configuration change.

In general, the fix is to add an explicit permissions block to the workflow (either at the top level or per job) that grants only the minimal required access for the GITHUB_TOKEN. Since this workflow only needs to read the repository contents (for checkout) and does not modify GitHub resources, we can safely restrict permissions to read-only.

The best, least-invasive change is to add a top-level permissions section right under the name: (before on:). This applies to all jobs (build-arm64 and create-manifest) without needing per-job blocks. The content should be:

permissions:
  contents: read

This grants only read access to repository contents, which is sufficient for actions/checkout@v3 and any implicit GitHub API reads needed by actions. No additional imports or dependencies are required; this is purely a YAML configuration change inside .github/workflows/release.yml.