chore(workflow): pin bonedigger lifecycle to clanker-queue rollout

[castrojo]

Pins bluefin's bonedigger caller to the new bonedigger rollout SHA so it can consume the clanker-queue migration workflow.

[hanthor]

This workflow change must follow the testing-first branch flow rather than target main directly. Please retarget it to testing, and refresh the pinned rollout SHA after the blocking changes on projectbluefin/bonedigger#33 are resolved.

[castrojo]

@hanthor thanks — reviewed both points, and a third one I found. Closing this rather than retargeting. Details:

1. Wrong base branch — confirmed

You are right, this targeted main and repo policy (AGENTS.md, docs/contributing.md) requires testing-first. Not fixing it in place because of point 2.

2. bonedigger#33 is still blocked — and the pin is unsound regardless

projectbluefin/bonedigger#33 is open, 4-review, with your CHANGES_REQUESTED unresolved:

• the clanker-queue/p0/p1 mapping still collapses cycle-wide hive priorities onto the repo-scoped priority/p0/p1 confirmation thresholds;
• the dual writes are still batched into a single gh issue edit ... || true, so a missing clanker-queue/* label suppresses the legacy update too;
• actionlint/pre-commit evidence still not attached.

Separately, the PR is now CONFLICTING with main.

The pin here is aa31855, which is the head of the feature branch feat/clanker-queue-rollout — verified via /branches-where-head. It is not on main and not behind a tag. Two problems:

• Pinning to a feature-branch head is a supply-chain regression versus the current d530767 # v1, which is the SHA of the v1 tag. Every other third-party reusable-workflow pin in .github/workflows/ follows the tag-SHA convention (projectbluefin/testsuite/...@ee2a5b9 # v1).
• Because docs: update README badges and links to projectbluefin org #33 is conflicting, it must be rebased to land, which will invalidate aa31855 outright. Any pin we merge now is guaranteed to go dangling.

So there is no "refresh the SHA" that is correct today. The right pin does not exist until #33 lands on main and is tagged.

3. Inputs do verify clean (for the record)

I diffed lifecycle.yml at both SHAs. Our with: inputs are safe either way — brand_name and brand_emoji are both still declared, both type: string with defaults, both optional (and both documented as "Retained for backward compatibility; ignored by the slim workflow"). aa31855 only adds pipeline_marker. No renames or removals, so this specific bump would not have broken at runtime.

The actual behavior delta at aa31855: adds clanker-queue/ready to the agent-donation label set, adds a new "Seed clanker queue triage labels" step writing status/triage + clanker-queue/triage, and dual-writes clanker-queue/p0/p1 alongside the legacy priority labels in both confirm-count paths — which is exactly the code your review flags.

4. Stale TODO — fixed separately

The adjacent comment claimed the pull_request: opened trigger needed restoring, but it is still present in the on: block, and it pointed at #TBD. Confirmed upstream lifecycle.yml has no pull_request jobs at either SHA (only on-issue-opened and on-issue-comment guards), so PR events dispatch the workflow and no-op.

Filed #981 as the real tracker and corrected the comment in #982, which targets testing and is independent of the rollout. just check and pre-commit run --all-files pass there.

Outcome

Closing. Reopen path: once bonedigger#33 has the priority mapping and independent dual writes resolved, lands on bonedigger:main, and is tagged (v2 or similar), a fresh PR against testing pinning that tag's SHA with a matching # v2 comment.

[castrojo]

Closed per the review above: blocked on projectbluefin/bonedigger#33 (open, changes requested, conflicting), and the pinned SHA is a feature-branch head that a required rebase will invalidate. TODO fix split into #982.