process-gap(pr-manager): PR labels not applied at create-pr step; manual workaround required for repos with label requirements

## Class of failure

The pr-manager agent creates PRs but doesn't apply repo-required labels at PR-creation time. If the target repo has a `PR Label Requirements` workflow that gates merge on label presence, the PR sits blocked until a human manually applies the label.

## Pattern observed

In an external pilot project with the following workflow rule:
```
# .github/workflows/pr-validation.yml — PR Label Requirements job
required_labels: [feature, chore, bug, docs] # at least one required
```

Each PR opened by pr-manager required a manual `gh pr edit --add-label feature` call to clear the required-status-check before merge could proceed. Pattern recurred across 4 consecutive PRs (every story PR).

## Root cause

The pr-manager step-3 (`create-pr`) currently invokes `gh pr create --title --body` without any `--label` argument. The orchestrator's dispatch prompt has been workarounding this with explicit instruction "apply `feature` label as part of step 3" — but this isn't codified in the pr-manager template.

## Proposed remediation

**Option A — Hard-code feature label**: pr-manager step 3 always applies `feature` label for story PRs and `chore` for chore PRs. Branch-prefix detection:
- `feature/STORY-*` → `feature` label
- `chore/*` → `chore` label
- `fix/*` → `bug` label
- `docs/*` → `docs` label

**Option B — Read project policy**: pr-manager reads `.factory/policies.yaml` (or `.github/labels.yml`) to determine which label to apply.

**Option C — Detect required-status-check**: pr-manager queries the target repo's branch protection settings to discover required labels and applies the most appropriate one based on branch prefix.

Option A is cheapest and covers the 90% case (story/chore/fix/docs branch conventions are near-universal in VSDD projects).

## Labels

- `process-gap`
- `pr-manager`
- `github-integration`