[FEATURE] Loop detection and configurable loop limits per workflow step

[JoshLuedeman]

Problem It Solves

Closes gap: #168

When a reviewer sends code back to the coder, the state file records the regression but tracks no iteration count, no loop history, and no maximum. A coder→reviewer→coder loop can spin indefinitely, accumulating cost and time with no automatic escalation.

Proposed Behavior

The workflow engine tracks re-entry counts per step in the state file. A loop_limit field in SKILL.md (or config.yaml as a default) sets the maximum number of times a step can be re-entered before automatic escalation:

# config.yaml
workflows:
  loop_limits:
    default: 3          # escalate to human after 3 re-entries of any step
    coder: 2            # coders get fewer retries before escalation

When a step exceeds its loop limit:

1. The engine emits a loop_limit_exceeded metrics event
2. The workflow transitions to a blocked state with reason: "Step N (coder) has been re-entered 3 times. Human review required before continuing."
3. teamwork next surfaces the blocked workflow prominently with the loop history

Loop history (timestamps, reasons for re-entry, handoff summaries per iteration) is stored in the state file and displayed by teamwork history.

Dependencies

• Relates to: [STATE] Add workflow checkpointing and resume capability #39 (checkpointing/resume) — loop history should survive session restarts
• Relates to: [GAP] Escalations are not first-class state transitions — no audit trail or agent routing #170 (escalation as first-class state transition)

Complexity Estimate

Medium — 3–4 files: state schema loop counter, engine loop detection, config schema extension, CLI display, tests