feat: add labels support to create_pull_request tool

### Describe the feature or problem you'd like to solve

The `create_pull_request` tool currently does not support adding labels during PR creation. Users who want to label PRs at creation time must make a separate `add_label` tool call after creating the PR, which adds friction in agentic workflows where a PR should be created with appropriate labels in a single step.

This is especially common in real-world usage — developers naturally say "create a PR and label it as bug" rather than thinking of it as two separate operations.

### Proposed solution

Add an optional `labels` parameter (string array) to the `create_pull_request` tool. Since the GitHub REST API (`POST /repos/{owner}/{repo}/pulls`) does not natively support labels, the implementation uses a two-step approach:

1. Create the PR via the existing pulls endpoint
2. Apply labels via `POST /repos/{owner}/{repo}/issues/{issue_number}/labels`

If label application fails after PR creation, the error clearly indicates the PR was created successfully but labels could not be applied, so no work is silently lost.

**Benefits:**
- Reduces tool calls needed for a common workflow (2 → 1)
- Aligns with how developers naturally think about PR creation
- Fully backwards-compatible — the parameter is optional
- Consistent with `issue_write` which already supports labels at creation time

### Example prompts or workflows (for tools/toolsets only)

1. **"Create a pull request from my feature branch to main and label it as `bug` and `priority:high`"** — Single-step PR creation with classification labels, common in triage workflows.

2. **"Open a PR for this hotfix, mark it as draft, and add the `urgent` label"** — Combines draft mode with labeling for time-sensitive fixes.

3. **"Create a PR titled 'Add user auth' from `feat/auth` to `develop` with labels `enhancement` and `security`"** — Full PR creation with multiple labels in one natural request.

4. **"Submit a pull request for my changes and tag it as `documentation`"** — Simple single-label use case that feels natural to say but currently requires two tool calls.

5. **"Create PRs for each of my feature branches and label them with their respective area labels"** — Batch automation scenario where reducing tool calls per PR matters.

### Additional context

I have a working implementation in PR #2413 that includes:
- Backend: `labels` array property in `CreatePullRequest` InputSchema + `AddLabelsToIssue` post-creation call
- Tests: 2 new test cases (success with labels, label failure after PR creation)
- UI: Labels input field in the `pr-write` MCP App
- Docs: Updated toolsnap + auto-generated README via `script/generate-docs`

All tests pass (`go test ./...`) and lint is clean (`golangci-lint run --new-from-rev=HEAD` → 0 issues).