Current release does not flash to sd using balena etcher and does not have correct sha256

### The current releases have the following issues:

The Signature files do not match the downloaded image files and the image files fail to flash using Balena Etcher. Using sha256sum on the following files yields the sum listed below it, but the sum you provided (below that) as you can see do not match:

CB1_Debian12_Klipper_kernel6.6_20241219.img.xz

Generated sha256sum
eff1412d4525c1ce9c6fe7135a771b2c507bfda5caf595a2b22735b68ebb9b24

CB1_Debian12_Klipper_kernel6.6_20241219.img.sha256
f9d9143bcb47ad6bd859c24eb9f06093385b9957d89e6493e520c401150584d7

CB1_Debian12_minimal_kernel6.6_20241219.img.xz

Generated sha256sum
b60f863f3a98d5e23642635aeca8d4f96550ddb470200aa8f14506f59d83829c

CB1_Debian12_minimal_kernel6.6_20241219.img.sha256
3d29eb529ab76b28190b73a5aa32e3864e1e9ca1229f41f8035da52f0c892b10

**What I discovered:**

Normally, one would take the sha256 from the actual file being offered for download, but after looking closely at the naming of the files I decided to extract the files from xz format since the sha256 filenames did not have .xz in them. So if I extract the file so that I truly am taking the sha256 of the image file as the name of the sha256 file would seem to indicate I get:

CB1_Debian12_Klipper_kernel6.6_20241219.img (without the .xz)

Generated sha256sum
f9d9143bcb47ad6bd859c24eb9f06093385b9957d89e6493e520c401150584d7

CB1_Debian12_Klipper_kernel6.6_20241219.img.sha256
f9d9143bcb47ad6bd859c24eb9f06093385b9957d89e6493e520c401150584d7

CB1_Debian12_minimal_kernel6.6_20241219.img (without the .xz)

Generated sha256sum
3d29eb529ab76b28190b73a5aa32e3864e1e9ca1229f41f8035da52f0c892b10

CB1_Debian12_minimal_kernel6.6_20241219.img.sha256
3d29eb529ab76b28190b73a5aa32e3864e1e9ca1229f41f8035da52f0c892b10

Since the download doesn't match the provided signature, it tends to make potential downloaders doubt the veracity of the download and potentially not use it. Furthermore, there is no instruction to extract the file prior to use, which would be very helpful. This is very confusing to encounter if you don't know to look VERY closely at the filenames.

Before coming onto the idea to extract first, I tried to use the previous release, and I had no problems with verifying since the sha256 was taken from the compressed file as I here suggest. I was also able to flash that older .xz version to an SD card without extracting it using Balena Etcher - I did not however attempt to use that before the idea of extracting first occurred to me.

Since it was able to flash the older .xz version, I'm not sure that it would have worked or if it had, why the newer .xz file would not flash at all.

My suggested change would be to provide the sha256 for the compressed file users will download, and then offer an instruction to extract the image file before using it.

Locate the release artifacts named CB1_Debian12_Klipper_kernel6.6_20241219.img.xz and CB1_Debian12_minimal_kernel6.6_20241219.img.xz, along with their .sha256 files and any release instructions. Verify the checksums against the downloaded compressed files and review the Balena Etcher extraction guidance. Done means the published hashes match the downloads and users are told when to extract the image before flashing.

Written by the indexing model from the issue text.