Add tool to list pull request policy evaluations

[Damien Lecan (dlecan)]

Summary

No tool reports why a pull request is blocked. repo_pull_request returns mergeStatus, votes and completionOptions, but never the policy results, and the statuses API does not cover branch policies. #843 raised this and was closed as completed without a tool shipping, same for #1276.

The policy evaluations API does cover them, and it is already reachable through getPolicyApi() in the official Node API. It also answers the original ask in #843: the context of a build evaluation carries buildId, buildDefinitionId, buildIsNotCurrent and isExpired, so a pull request id can be traced to its build validations.

Tools

Develop the following tool with full parameter support, including optional ones:

repo_list_pull_request_policy_evaluations: List branch policy evaluation results for a pull request.

Endpoint: GET https://dev.azure.com/{organization}/{project}/_apis/policy/evaluations?artifactId=vstfs:///CodeReview/CodeReviewId/{projectId}/{pullRequestId}&api-version=7.1-preview.1

REST docs: https://learn.microsoft.com/en-us/rest/api/azure/devops/policy/evaluations/list

Node API: getPolicyApi().getPolicyEvaluations(project, artifactId, includeNotApplicable?, top?, skip?)

Three things worth knowing before implementing, all verified against a live organization:

• the artifact id is vstfs:///CodeReview/CodeReviewId/{projectId}/{pullRequestId}, not the vstfs:///Git/PullRequestId/... value that repo_pull_request returns for the same pull request;
• api-version=7.1 is rejected, the preview suffix is required;
• the response should keep status, configuration.id, configuration.isBlocking, configuration.type.displayName and context. Callers need configuration.id to match against completionOptions.autoCompleteIgnoreConfigIds, because a policy with isBlocking: false still holds auto-complete unless its id is listed there. Without that pairing, a pull request whose every readable field says "ready to merge" can sit unmerged with no way to explain it.

Rules

1. Adhere strictly to existing project standards and coding conventions.
2. Ensure each tool exposes all API parameters (required and optional).
3. Use the official Azure DevOps Node API to interact with the APIs.

I can test a build of this against a live organization with the policies above, and open a PR if that helps.