[Bug]: Maintenance builds don't create corresponding packages for the apt repo

### What happened?

This isn't an issue with the build framework, explicitly, but an issue with the release management process overall.

A forum user reported a problem where they can't install the correct version of kernel headers for the version of the kernel they have installed (https://forum.armbian.com/topic/42376-helios64-kernel-headers-for-this-kernel-do-not-seem-to-be-installed/). This happens every release, and isn't a new issue.

From what I witness, this is what is happening:
1) Original release goes out (24.5.1) in this case, all images are built and the apt repository is populated with the corresponding packages and everything is in sync at that time.
2) Issues need to get addressed and maintenance images are produced (24.5.2, 24.5.3, etc) These images appear to be built off of current main branch of armbian/build (not a patched version of the 24.5 branch). So instead of picking up all the same versions of referenced code (that we pinned at the time we froze the original release), it picks up the current patch release level of the kernel (and other code as well). So these images built for a maintenance release (24.5.2, 24.5.3, etc) end up including newer versions of the kernel than 24.5.1 was released with. But these new kernel packages aren't also put in the apt repository.
3) So when a user goes to install an additional package (like the kernel headers) after installing 24.5.3, the version in the apt repo doesn't match the version of the kernel they have in their image. And thus you have the problem reported by the user.

From my perspective the correct way to produce maintenance releases is that the desired changes should first be made and tested in mainline armbian/build and then backported to the release branch (24.5 in this case). And then images should be produced from that branch, otherwise you can't really control what changes you are incorporating into a maintenance release.
With the logic added this year to pin all dependencies, this should result in dependencies consistent with the original release. Of course any artifacts that change as a result of what was fixed in armbian/build (likely to be uboots, kernels, etc), should be also be versioned correctly and added to the apt repo. I don't know if the current packaging versioning logic can handle that case, (i.e. can you have a 24.5.1 and a 24.5.3 version of the same kernel i.e. 6.6.36?)

With consistent builds (coming from a mostly stable branch) and corresponding artifacts being pushed to the apt repo, a user should always be able to have access to the corresponding .debs for their image and be able to install anything needed (generally, kernel headers, but it could be for a minimal install other packages like armbian-config).

### How to reproduce?

Described above.

### Branch

main (main development branch)

### On which host OS are you running the build script and observing this problem?

Ubuntu 24.04 Noble

### Are you building on Windows WSL2?

- [ ] Yes, my Ubuntu/Debian/OtherOS is running on WSL2

### Relevant log URL

_No response_

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct