feat: Implement pre-release strategy for unstable channels

[mairas]

Problem

The current workflow assumes unstable channel packages come from GitHub releases, but main branch pushes don't automatically create releases. This creates a gap between the unstable channel workflow and actual package availability.

Proposed Solution

Implement automatic pre-release creation in package repositories:

On push to main

Package repository workflows should:

1. Build the package with version from the commit (e.g., v1.2.3)
2. Create a GitHub release with that version tag (e.g., v1.2.3)
3. Mark the release as a pre-release using GitHub's pre-release flag
4. Attach the .deb artifact to the release
5. Send repository_dispatch to apt.hatlabs.fi with channel: "unstable"

Tagging Convention

• Use normal semantic versioning for tags: v1.2.3, v1.2.4, etc.
• No special tag format required - the pre-release flag is what distinguishes them
• Release title can mention "Automatic pre-release" for clarity
• Each push to main creates a new versioned pre-release

Full Rebuild Support

The apt.hatlabs.fi workflow can perform full rebuilds of unstable distributions by:

• Querying for the latest release (including pre-releases)
• Comparing version numbers to determine newest
• Using artifacts from the latest pre-release OR latest stable release (whichever is newer)

Benefits

1. Standard versioning - Same tag format as stable releases
2. Version tracking - Each unstable build has a proper version
3. Rollback capability - Can reference specific unstable versions
4. Full rebuild support - Scheduled/manual rebuilds can populate unstable channels
5. Cleaner workflow - apt.hatlabs.fi treats all releases uniformly

Implementation Example

name: Build Unstable
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Get version
        id: version
        run: echo "version=$(cat VERSION)" >> $GITHUB_OUTPUT

      - name: Build package
        run: # ... build .deb with version from step above

      - name: Create pre-release
        uses: softprops/action-gh-release@v1
        with:
          tag_name: v${{ steps.version.outputs.version }}
          name: v${{ steps.version.outputs.version }} (Automatic pre-release)
          prerelease: true
          files: "*.deb"

      - name: Trigger APT repo update
        run: |
          curl -X POST \
            -H "Authorization: token ${{ secrets.REPO_DISPATCH_TOKEN }}" \
            https://api.github.com/repos/hatlabs/apt.hatlabs.fi/dispatches \
            -d '{"event_type":"package-updated","client_payload":{"distro":"trixie","channel":"unstable"}}'

Migration Path

1. Update one package repository as proof of concept
2. Verify apt.hatlabs.fi workflow handles pre-releases correctly
3. Test full rebuild mode with pre-releases
4. Roll out to all package repositories
5. Document the pattern for new repositories

Related Issues

• Depends on feat: Implement multi-distribution APT repository support #9 (Multi-distribution support)
• Related to feat: Implement per-distribution package filtering #11 (Package distribution separation)

Acceptance Criteria

• Package repos create versioned pre-releases on main branch pushes
• Tags use normal semantic versioning (v1.2.3)
• Pre-release flag is set correctly
• apt.hatlabs.fi successfully downloads from pre-releases
• Full rebuild mode populates unstable channels correctly
• Unstable channel updates work end-to-end
• Documentation updated with unstable channel workflow
• At least one package repository fully migrated

---

🔧 Implementation Requirements

MANDATORY: Follow halos-distro/docs/DEVELOPMENT_WORKFLOW.md during implementation.

See the complete workflow at: https://github.com/hatlabs/halos-distro/blob/main/docs/DEVELOPMENT_WORKFLOW.md

✅ Implementation Checklist

Track your progress through the mandatory development workflow:

□ Phase 1: EXPLORE (No Coding!)

• Read GitHub issue completely
• Read /docs/SPEC.md relevant sections (if applicable)
• Read /docs/ARCHITECTURE.md relevant sections (if applicable)
• Explore existing code WITHOUT writing anything
• Use Task tool with subagent_type=Explore for complex navigation

□ Phase 2: PLAN

• Use think hard to evaluate approaches
• Create detailed implementation plan
• Identify test scenarios
• Document plan in comment/file

□ Phase 3: TEST (TDD)

• Write comprehensive tests FIRST
• Verify tests FAIL (no mocks)
• Commit tests: git commit -m "test: add X tests"

□ Phase 4: IMPLEMENT

• Write code to pass tests
• Run tests after each change
• DO NOT modify tests to pass
• Iterate until ALL tests pass

□ Phase 5: VERIFY

• Use subagents to verify correctness
• Check for edge cases
• Verify matches requirements
• Ensure follows architecture patterns

□ Phase 6: COMMIT

• All tests pass
• Code linted and formatted
• Type checks pass
• Commit: git commit -m "feat: implement X\n\nFixes #12"
• Create PR if needed