feat: add labels support to create_pull_request tool

Bắt đầu bằng việc xem xét PR #2413 cùng với CreatePullRequest InputSchema, lệnh gọi AddLabelsToIssue, các bài kiểm thử và những thay đổi của pr-write MCP App được nêu trong issue. Chạy go test ./... và golangci-lint run --new-from-rev=HEAD; công việc được xem là hoàn tất khi các label tùy chọn hoạt động, lỗi label báo rõ rằng PR đã được tạo và các công cụ được ghi lại trong tài liệu đã được cập nhật.

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