Correct activation label targeting and verify it end to end #1957

Problem

The merged label-provisioning change assumes create_issue returns a real GitHub issue number during the agent run, then instructs add_labels to target that number. In gh-aw, issue creation is deferred to the safe-output job and the agent receives only a success result—not the created issue number.

This leaves activation label application unreliable: labels may target the triggering issue when no item number is supplied, target an incorrect issue if a number is inferred, or be skipped. The recommended /squad activate fast path also retains the previous label behavior and may not provision missing labels.

Required correction

Use gh-aw's supported temporary-ID relationship between safe outputs:

1. Require and assign a unique temporary_id to every activation create_issue request.
2. Target the matching issue from add_labels using that temporary ID.
3. Apply the same behavior to both the complete plan activate path and the recommended /squad activate fast path.
4. Update activation reporting so it attributes labels to successful add_labels operations rather than claiming they were carried by create_issue.
5. Ensure configured operation limits cover the maximum supported activation without silently dropping label operations.

Success criteria

• On a fresh repository containing no Squad labels, both supported activation paths create required labels without manual setup:
  • /squad plan activate
  • /squad activate
• Every created or reused epic/task is addressed using an explicit, unique temporary ID or a verified existing issue number; no issue number is predicted or inferred.
• Every add_labels request explicitly targets its matching activation item.
• The triggering intent issue never receives a task or epic owner label accidentally.
• Every activated issue receives the base squad label.
• A task with a certified roster owner receives exactly its own squad:{agent} label.
• @copilot maps to squad:copilot.
• Multi-owner epics receive only squad; non-roster values follow the existing explicit omission/reporting contract.
• Activation summaries report labels actually applied by successful label operations, not labels merely intended or requested.
• Re-running activation is idempotent: no duplicate issues, duplicate bindings, or inconsistent labels are produced.
• The configured safe-output maximum supports the workflow's documented maximum activation size; exceeding any limit causes an explicit activation failure or incomplete report rather than silent truncation.
• Tests validate compiled safe-output schemas and the temporary-ID linkage between each create_issue and add_labels request. Tests must fail if targeting is omitted, uses the triggering issue implicitly, or relies on a returned real issue number.
• All Squad workflows compile successfully with gh-aw strict mode and targeted tests pass.
• E4 is rerun against a fresh repository after the correction. It demonstrates successful label creation, correct per-task correspondence, correct multi-owner behavior, no accidental labels on the origin issue, and a truthful activation summary. The E4 evidence/status document is updated with the run URL and result.

Scope

This issue is limited to correcting and proving activation label targeting. Distribution of the separate deterministic post-activation checker and post-activation implementation behavior remain out of scope.