Add riscv64 architecture to Docker workflow logic (tracking issue)

Nobody has claimed this yet.

Let's consider again support for RISC-V.

At the time of PR # 320 it was early to commit support when only first and second generation hardware is commercially available, and some doubt about the pace of software ecosystem adoption. Now is some months later and the availability of next generation hardware while also more mainstream adoption continues.

The cargo-chef build workflows have also since been improved and there is factored out the maintenance overhead now compared to then and add support in the new workflows.

- [x] LukeMathWalker/cargo-chef#320 Closed un-merged
- [ ] LukeMathWalker/cargo-chef#352 Follow-up submission

Addressing concerns raised previously, here are some contributing factors why this may now be appropriate and considered:
- The microcontroller industry is meaningfully shifted over to embrace RISC-V in addition to or replacing new designs. A majority of products designed having an integral RISC-V instruction set are actively sold at quantities aligned with continued mass-production i.e. the instruction set and development tools are already mainstream.
- Linux kernel 7.0 release promotes Rust language status to official and end of "experimental" support status; some of the first in-tree uses of Rust in Linux Kernel are RISC-V hardware drivers
- Rust language itself [riscv64gc-unknown-linux-gnu](https://doc.rust-lang.org/rustc/platform-support/riscv64gc-unknown-linux-gnu.html) is Tier 2 with Host Tools; [riscv64gc-unknown-linux-musl](https://doc.rust-lang.org/rustc/platform-support/riscv64gc-unknown-linux-musl.html) is Tier 2 without Host Tools. This seems due for an upgraded status change again as all Alpine Linux distro (musl) with "main" Alpine Linux support levels (currently v3.20+) have RISC-V as supported, and the most recent end-of-support Alpine Linux release (v3.19) not supporting RISC-V is end-of-life later this year. This may be "chicken and egg" situation where Rust foundation needs proof of use before upgrading support level, and proof of use waits on upgraded support level... yet anyways existing cargo-chef release workflow improvements allow this is automated, the glibc targets can build as expected and if musl builder images are listed in future it will be added to releases without additional work.
- PyPI had accepted the proposal for and is since June of the previous year now live with tier-1 riscv64 package support
- RISE RISC-V project offers GitHub Actions self-hosted runners for free use to spur adoption. At the moment it is Ubuntu 24.04 with second-generation RVA20/RVA22 hardware, and planned Ubuntu 26.04 when next-generation RVA23 profile capable hardware gets racked. Although the second-generation hardware on the Ubuntu 24.04 runners is not particularly fast, these are actively maintained and convenient if you don't mind the "not going to argue with the price of 'free'" speed of the older hardware.
- Qemu riscv64 on GitHub official amd64 runners is comparable or quicker than second-generation riscv64 hardware due to more cores and more memory. The use of Qemu for riscv64 GitHub Actions workflows is not any problem.
- RVA23 profile hardware (SpacemiT K3 System-on-Chip via several vendor board offerings) is now commercially available with actively maintained upstream Linux kernel and Ubuntu 26.04 distro support.
- A majority of RISC-V RVA20 or RVA22 profile compatible hardware may run their compiled binaries on new-to-market hardware with the RVA23 profile. Distros e.g. Alpine Linux 3.20 3.21 3.22 3.23, Ubuntu 24.04, RockyLinux 10, Fedora 43, and Debian 13 Trixie, targeting profiles before RVA23 do not get the performance gain of RVA23 Vector extension but do remain forward-compatible to RVA23 required by Ubuntu 26.04+.
- There are several System-on-Chip with RVA20 or RVA22 profile currently in production and available since 3+ years previous with upstream Linux kernel support. Even with the ongoing demand-side impact of A.I. industry delaying next-generation product supply-side there are widely distributed available in-stock SBC products with second-generation RISC-V SoC today that are older designs well-supported in aforementioned stable mainstream distros.

Sorry about that wall of text but I want to be thorough addressing the concerns. I'm trying to contribute to RISC-V enablement of GitHub actions workflows for projects that I am interested in. Dependency on cargo-chef is a blocker for making progress without increasing burden on maintainers. I want to make this the best pitch for adoption in all the dependencies of those projects I am interested in, that I can, so that those maintainers will not have to take on additional work for RISC-V enablement either.

Start by reviewing the cargo-chef build workflows and the follow-up submission tracked in LukeMathWalker/cargo-chef#352. Determine where architecture-specific Docker workflow logic is maintained and verify that riscv64 builds are included without adding ongoing maintenance burden; completion should be demonstrated by the relevant workflow runs.

Written by the indexing model from the issue text.