unify pkg workflows: remove standalone debusine callers

[Simon Beaudoin (simonbeaudoin0935)]

Problem

Some pkg-* repos still carry standalone debusine-* caller workflows from the earlier siloed integration, while current org-wide pkg-* workflows already support the unified model:

• Debian builds/releases via Debusine
• Ubuntu builds/releases via Docker/pkg-builder

This leaves duplicate entry points and mixed conventions across repos.

Goal of this PR

Make the pkg-* workflow path the single org-wide flow and remove legacy debusine-* caller workflow drift, while preserving the behavior needed for Debian (Debusine) and Ubuntu (Docker) paths.

What This PR Changes

1) Unified PR bridge and build/release parity

• Adds/aligns PR bridge templates:
  • .github/pkg-workflows/debian/pkg-pr-hook.yml
  • .github/pkg-workflows/qli-ci/pkg-pr-check.yml
• pkg-pr-check now triggers only from PR Build Hook.
• PR status context is consistently PR Build (no Debusine-only wording).
• Replaces actions/github-script status posting with bash + GitHub REST API (curl).
• Aligns reusable build/release contracts for Debian paths:
  • branch/suite resolution updates (including latest -> forky Debusine mapping and Docker fallback handling)
  • explicit source-ref handling for PR merge refs
  • explicit Debusine release outputs/inputs (debusine_target_workspace, package_version_identifier)
  • keep public Test job/container behavior stable.

2) Workflow sync migration behavior

• Updates .github/workflows/workflows_sync.yml to:
  • explicitly sync pkg-pr-check.yml with default-branch workflow templates
  • remove legacy standalone debusine-*.yml / debusine-*.yaml during sync
  • apply that cleanup across default-branch sync and managed branch cleanup passes.

3) Promotion PR branch namespace cleanup

• Renames promotion PR branch pattern:
  • from debian/pr/<version>-1
  • to promotion-pr/<version>-1
• Applies to both promote workflows and helper script:
  • .github/workflows/pkg-promote-reusable-workflow.yml
  • .github/workflows/pkg-promote-prebuilt-reusable-workflow.yml
  • scripts/create_promotion_pr.py
• Updates docs and sync filtering to match the new namespace.

Explicit Parity Notes (for legacy Debusine workflow review)

• This PR does not remove Debian Debusine build/release behavior.
• It removes duplicate standalone caller workflow files and routes PR/build/release entry points through the unified pkg-* flow.
• Debian still resolves to Debusine path when secrets/inputs are available.
• Ubuntu remains on Docker/pkg-builder path.
• PR bridge remains the mechanism to run privileged build logic outside direct untrusted PR context while reporting status back to the PR head SHA.

Non-goals

• No attempt here to redesign package-specific build logic.
• No attempt here to change artifact publication policies beyond the branch-prefix rename for promotion PR branches.

Commit Structure (cleaned)

1. pkg: unify PR bridge and build-release parity
2. pkg-pr: finalize hook/check status wiring
3. sync: remove legacy debusine workflows
4. promote: use promotion-pr branch prefix

[Robie Basak (basak-qcom)]

This PR does not remove Debian Debusine build/release behavior.
It removes duplicate standalone caller workflow files and routes PR/build/release entry points through the unified pkg-* flow.

Sorry, I don't understand. I'm still actively maintaining these workflows and tech teams are currently actively using them. I agree with converging them. But what's the migration plan here?

[Simon Beaudoin (simonbeaudoin0935)]

Robie Basak (@basak-qcom)

But what's the migration plan here?
< The plan is after this PR is merged, there is no more need to have the debusine-* workflows, since all the logic will have been migrated over to the pkg-* workflows. Then we can finally all maintain and work on one set of files. Then, once this is merged, we run the workflow_sync.yml workflow, and it will sync the workflows and delete the debusine-* workflows accross the pkg-repos

[Robie Basak (basak-qcom)]

Have you checked that everything implemented by the existing Debusine flows is correctly available in the flows that will replace them? How are you validating this? This is a hard prerequisite.

When we discussed this the other day we said I'd do this, but I'm working on the priority ordered list that we agreed at the time, and we haven't got down this far yet. Repository configuration management was a higher priority. So I haven't looked at this yet.