Plan and prepare CirrOS 0.6.4 release

[SeanMooney]

Goal

Plan and prepare a CirrOS 0.6.4 patch release.

The intent is to release the accumulated post-0.6.3 fixes plus low-risk fixes
needed by current users, without turning this into the larger Buildroot/kernel
baseline refresh that should happen in a future 0.7.0 cycle.

Motivation

The maintenance/release discussion in #131 identified a practical need for a new
release that includes the work already merged after 0.6.3 and the new image
variant work from #132.

A key motivation is the boot-from-volume/rootfs-copy concern discussed in #131:
the traditional qcow2 image starts with an empty/minimal root filesystem and
copies the initramfs content into it during first boot. If that boot is
interrupted, the resulting root filesystem can be partially populated. The new
*-full.qcow2 variant from #132 provides a pre-populated root filesystem while
preserving the traditional behavior as *-minimal.qcow2.

Issue #134 also reports a low-risk diagnostic bug in the EC2 datasource debug
message. PR #135 fixes that by logging the actual metadata endpoint used for
instance-id.

Proposed 0.6.4 scope

Include:

• upstream main changes since 0.6.3, including the riscv64-related build and
  CI fixes already merged;
• Add Docker-based CirrOS build environment #132, the Docker/build and qcow2 image variant stack;
• Add a CirrOS developer guide #137, the developer guide documentation PR;
• Clean up part2disk loop mappings #136, guarded part2disk loop/device-mapper cleanup, which is currently
  stacked on Add a CirrOS developer guide #137;
• correct the password in README to gocubsgo #130, README default-password correction;
• Fix misleading EC2 instance-id metadata debug URL #135, EC2 datasource debug URL correction for EC2 datasource logs misleading instance-id metadata URL #134.

Defer:

• Update build-release to ubuntu 24.04 kernel! #125, Ubuntu 24.04 kernel/grub update, to a future 0.7.0 baseline refresh.

Candidate PR decisions

PR	Proposed decision	Rationale
#130	Include in 0.6.4	README-only correction of the documented default password from letsgocubs to gocubsgo. This is a low-risk user-facing correctness fix suitable for a patch release.
#135	Include in 0.6.4	Diagnostic-only EC2 datasource debug-message fix for #134. It makes the logged URL match the actual meta-data/instance-id endpoint and should not alter datasource behavior.
#137	Include in 0.6.4	Adds the developer guide documenting the new Docker/build, artifact, boot-test, and release workflows. This is also part of the current stack because #136 is based on #137.
#125	Defer to 0.7.0	Moves the release build to Ubuntu 24.04 kernel/grub inputs, is currently conflicting, and has known follow-up implications for .ko.zst module handling in bin/bundle. This is better handled as part of a 0.7.0 modernization cycle.

Open decisions

• Should riscv64 be published as part of 0.6.4, or remain treated as
  experimental/CI-only output?
• Is the current Add Docker-based CirrOS build environment #132 -> Add a CirrOS developer guide #137 -> Clean up part2disk loop mappings #136 stack ordering acceptable for the release,
  or should the documentation and loop-cleanup changes be reordered before
  tagging?
• What exact commit should be tagged as 0.6.4?
• Should 0.6.4 use only GitHub Actions artifacts, a local maintainer build, or
  both for verification?
• What is the current canonical signing and publication process for
  download.cirros-cloud.net and simplestreams metadata?

[SeanMooney]

note once all of the resetnt PRs above have merged we will need one release prep pr to update the changelong for the content of 0.6.4 which shoudl ideally be the commit that we tag as 0.6.4