chore(ci): enable SonarCloud scan on pull-request builds

[alexandru-petre]

Context

This repo's Azure Pipelines run a SonarCloud scan as part of the per-pack build (Cryptography, Database, FTP, Java, Python, Credentials). PR #559 vendored the Sonar templates locally and restored Sonar after a long outage, but PR-time scanning was held back behind an explicit ne(Build.Reason, 'PullRequest') guard while a separate SonarCloud-admin punch list was worked through.

Problem Statement

PR builds currently skip Sonar entirely — no scan, no PR decoration, no coverage delta comment on GitHub. Reviewers and contributors get no early signal on code-quality or coverage regressions until after merge to develop, which is too late to course-correct.

Behavior Before This PR

A contributor opens a PR against develop. The pack pipeline runs Build → Test successfully, and then:

• PublishSonar stage is skipped (PR builds excluded by Build.Reason guard).
• SonarCloudPrepare and the post-build Sonar upload steps inside the Build stage are also skipped by the same guard.
• No SonarCloud comment is posted to the GitHub PR; the Pull Requests tab in SonarCloud stays empty for this PR.

Behavior After This PR

Same scenario — a contributor opens a PR against develop from a same-repo branch. The pack pipeline runs Build → Test, and then:

• SonarCloudPrepare runs in the Build stage.
• The post-build Sonar artifact is uploaded.
• PublishSonar stage runs: merge-commit reconstruction (already in place since chore(ci): vendor AzurePipelinesTemplates, restore Sonar, harden CI #559)
• SonarCloud posts a PR comment with quality-gate status, coverage delta, and new-code findings; the PR appears in SonarCloud's Pull Requests tab.

Fork PRs and direct pushes to masters/* / support/* remain excluded — the IsFork guard and the startsWith branch exclusions are preserved on all three conditions.

Implementation

The change removes one clause (ne(variables['Build.Reason'], 'PullRequest')) from three condition: expressions and tightens the prose comment block that previously documented the temporary exclusion. The deleted SONARCLOUD_ADMIN_CHECKLIST.md was a hand-off document for the SonarCloud admin work that gated this restoration — all four of its steps (main branch rename, long-lived branch pattern, Automatic Analysis off, baseline) are now done.

Caveats / Potential Issues

• First PR's quality gate may fail spuriously. Sonar was off for ~3 months (since 2026-02-27). When develop re-baselines, the first PR scans against a fresh baseline and may flag accumulated drift as "new code", failing the gate purely on coverage delta. If this happens, the SonarCloud admin should set Administration → New Code → Specific date to just before the first restored analysis on develop. This is a SonarCloud-side knob, not a pipeline change.
• Same-repo PRs from feature branches do receive the SONARQUBE_ENDPOINT secret; only fork PRs strip secrets, and those remain excluded by the IsFork guard.

How to Test

1. This PR is the test — once the build runs, confirm:
   • The pack pipelines no longer show PublishSonar as skipped on this PR.
   • SonarCloudPrepare, SonarCloudAnalyze, and SonarCloudPublish each show a green check in the build log.
   • A SonarCloud bot comment appears on the GitHub PR with quality-gate status.
   • The PR is listed under https://sonarcloud.io/project/pull_requests_list?id=UiPath_Community.Activities.
2. After merge, push any commit to a masters/* or support/* branch and confirm Sonar still skips those direct pushes (the startsWith guards still apply).