feat: add labels support to create_pull_request tool

Inizia esaminando la PR #2413 e il CreatePullRequest InputSchema, la chiamata AddLabelsToIssue, i test e le modifiche a pr-write MCP App indicate nell'issue. Esegui go test ./... e golangci-lint run --new-from-rev=HEAD; il lavoro è completato quando le label opzionali funzionano, gli errori delle label indicano chiaramente che la PR è stata creata e gli strumenti documentati sono aggiornati.

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).