fix: seed hotfix resolution-PR labels before gh pr create

[joshua-temple]

Problem

The generated cascade-hotfix workflow opens its resolution PR on the cherry-pick conflict path with gh pr create --label cascade-hotfix-conflict, but that label is never created. gh pr create --label X fails hard when X does not exist, so any conflicting cherry-pick dies at the "Cherry-pick and open resolution PR" step and no resolution PR opens. The clean path (--label cascade-hotfix) had the same latent exposure: the only label seed was an operator-pasted suggestion from the plan verb, never run by the workflow itself.

Fix

• Add an "Ensure hotfix labels exist" step to the generated apply job that runs gh label create cascade-hotfix and gh label create cascade-hotfix-conflict (each || true for idempotency) before any PR is opened.
• Grant issues: write on the workflow. gh label create hits the labels API and returns 403 without it; combined with || true that would silently no-op and leave the bug intact.
• Introduce package-level label constants in both packages that reference the label, with cross-package sync comments, so the seed and the gh pr create consumer cannot drift.
• Extend the plan verb's protection suggestions to also seed the conflict label.

Verification

• go build ./..., go test ./... (1396 pass), golangci-lint run ./... clean.
• e2e module go build + go vet clean.
• New unit test TestHotfixGenerator_SeedsLabels asserts both label seeds render and the seed step precedes the cherry-pick step; confirmed failing before the fix, green after.
• e2e: the gitea harness creates PR labels on demand and so cannot reproduce the real-GitHub missing-label hard-fail. The strongest faithful guard is a workflow_files assertion in the existing conflict-resolution scenario that the materialized cascade-hotfix.yaml seeds both labels and requests issues: write.