Create missing Squad labels during plan activation #1955

Problem

/squad plan activate promises to create routable work items labeled with squad and the corresponding squad:{agent} owner. On a fresh consumer repository, those labels may not exist. The current workflow has only issues: read at the agent level and no label-management safe output, so activation omits unavailable labels and reports a prerequisite gap.

This means the end-to-end /squad cast through plan activate experience does not reliably deliver the labeled issues described in the documentation.

Proposed change

Use gh-aw's supported label-management safe output with tightly scoped permissions, for example:

safe-outputs:
  add-labels:
    allowed: [squad, "squad:*"]
    create-if-missing: true
    issues: true

Keep the main agent read-only. Create missing labels through the generated safe-output job, then ensure each activated issue receives squad and, when valid, the squad:{agent} label derived from that issue's own planning row.

Acceptance criteria

• A fresh repository with no Squad labels can run the supported flow through plan activate without manual label provisioning.
• Missing squad and valid squad:{agent} labels are created through gh-aw safe outputs.
• Every activated work item receives the base squad label.
• Work items with a certified roster owner receive the matching squad:{agent} label.
• Label correspondence is derived from each issue's own source row, not its parent or a previous item.
• @copilot maps to squad:copilot; uncertified or multi-owner values follow the existing explicit reporting behavior.
• Re-running activation is idempotent and does not create duplicate issues or inconsistent labels.
• Workflow documentation no longer describes manual label provisioning as a prerequisite.
• Contract tests cover safe-output configuration, missing-label creation, roster binding, correspondence, and reruns.
• The E4 activation verification is rerun against a fresh repository and records a successful second run.
• The workflow compiles successfully in strict mode.

Scope

Limit this issue to label creation and application in the existing issue-comment planning journey. Post-activation implementation behavior is out of scope.