feat: Enable import & extend, nightly schedule

[jinnatar]

Primarily:

• Enable nightly scheduled runs so that it does what it says on the tin.
• Enable importing the current mirror as the basis of runs so that nightly runs don't drop stable.

Also:

• Fixes Instructions are incorrect currently #6 portion where kanidm_ppa.list has the wrong key suffix.

[yaleman]

Fun thing with GHA, while I think about it - if there's no changes for "60 consecutive days" they disable the actions runners so we need to periodically touch something in THIS repo to keep the cron job working, so might be worth adding a "push a touched file" step somewhere.

[jinnatar]

There's some other fundamental issues here as well:

• This would work as written, BUT if any change is merged to main afterwards, the import of previous stable will conflict with the new builds of the same stable.
• I don't really think mutating the matrix all the time is a solution, so that leaves finding a different trigger for the stable matrix. Could be deployment but I don't have experience with that. Could be release, easier to deal with.
• But in any case version dedupe needs to be a thing, probably by increasing debian_rev but then it has to be done in the main repo, very hard to increment downstream.

So as much as it pains me, we might be better off merging back into the main repo? 😑

[yaleman]

I don't see a huge issue merging most of it back into main - but we really need the automation to be outside main as much as possible (or very very specifically filter its execution)

[jinnatar]

If stable publishing only triggers on release then that would stay out of the way most of the time. That logic can be tested in this repo first. For nightly, we could only trigger on schedule normally, but also on PRs that have a specific tag to allow useful PRs against the automation itself. That way nothing triggers on push i.e. merge, or on most PRs. Would that work? It's probably the the sweet spot between competing issues of:

• Does not die on it's own every 60 days. (rules out separate automation repo)
• Doesn't hold the automation code in a repo that has so much binary history it's unusable. (rules out automation + mirror in the same repo)
• Has organic triggers to build stable. (Probably only possible in the main repo)
• Allows manual jiggery pokery if things go horribly wrong (modifying repo state in kanidm_ppa if some rogue GenAI takes over GHA and trashes it. Or the automation fails in unexpected ways.)