Investigate remaining explicit workflow.requeue path moving Refining -> To Do after #227 live

[fujiwaranosai850]

We need a new follow-up issue for the still-live loop path that remains after #227 was merged and loaded into the running devclaw-local-dev environment.

Why this is a separate issue

Issue #227 identified and fixed one remaining stale-snapshot / heartbeat-health race. That fix is now live, but PhysioLink issue #74 is still looping.

The latest evidence shows a different or additional path is still active.

Current live evidence

With the #227 fix live, PhysioLink #74 still shows this pattern:

• worker blocks correctly: Doing -> Refining
• then the system emits an explicit workflow.requeue event: Refining -> To Do
• then heartbeat dispatches it again: To Do -> Doing

This is important because the loop is no longer explained purely by a stale active-state dashboard or stale-snapshot overwrite. The event timeline shows a real normalized workflow.requeue transition being recorded after the hold state.

What this means

The currently live fix from #227 did not stop the full loop family.

There is still at least one active requeue path in the system that is deliberately moving held issues from Refining back into runnable queue state.

Scope to investigate

Focus specifically on code paths that can emit or cause a workflow.requeue after a blocked/hold transition, including but not limited to:

• heartbeat pickup/repair logic beyond the stale-snapshot fix from Investigate post-intervention regression family behind blocked-hold redispatch loops not fixed by #225 #227
• any remaining queue repair or slot-recovery paths that call the same requeue machinery
• task_start / queue transition helpers used by automated repair flows
• any shared code introduced or reshaped during operator-intervention-era changes that can still legally produce a requeue from a hold state
• any project/workflow-specific differences that make PhysioLink Stop poisoned dev/review loops and enforce recovery when PR branches become structurally invalid #74 reproduce after the DevClaw-local fix

Reproduction anchor

Primary reproduction case:

• PhysioLink issue Stop poisoned dev/review loops and enforce recovery when PR branches become structurally invalid #74
• worker repeatedly blocks because work_finish(done) mis-resolves the PR branch
• issue moves Doing -> Refining
• system later records workflow.requeue: Refining -> To Do
• issue dispatches again

Acceptance criteria

• Identify the exact remaining code path that emits or causes workflow.requeue from Refining to To Do after a blocked worker result.
• Fix it without breaking normal explicit human restarts.
• Add regression coverage for the explicit workflow.requeue after hold case, not just stale snapshot behavior.
• Verify the fix against PhysioLink Stop poisoned dev/review loops and enforce recovery when PR branches become structurally invalid #74 in the live environment.

Relationship to existing issues

• Blocked/Refining issues are being auto-requeued back into runnable developer state #225 fixed one blocked-hold overwrite/requeue path.
• Investigate post-intervention regression family behind blocked-hold redispatch loops not fixed by #225 #227 fixed another stale-snapshot / heartbeat-health path.
• This issue is for the still-live explicit requeue path that remains after both fixes.