ci(triage): use pull_request_target so labeler can write on fork PRs

[afonsojramos]

Summary

Switches the Triage workflow trigger from pull_request to pull_request_target so the auto-labeler can actually apply labels and post a commit status on PRs from forks (e.g. #2845), where GITHUB_TOKEN is forced read-only under pull_request.

Safe because neither job in this workflow checks out PR code — both pinned actions (action-semantic-pull-request, multi-labeler) only read PR metadata via the API, with no shell interpolation of untrusted PR fields.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[setchy]

This was our workflow config prior to #2763 where we addressed some feedback from zimzor / actionlint

[setchy]

https://docs.zizmor.sh/audits/#dangerous-triggers

Many online resources suggest that pull_request_target and other dangerous triggers can be used securely by ensuring that the PR's code is not executed, but this is not true: an attacker can often find ways to execute code in the context of the target repository, even if the workflow doesn't explicitly run any code from the PR. Common vectors for this include argument injection (e.g. with xargs), environment injection (e.g. LD_PRELOAD), and local file inclusion (e.g. relinking files to the runner's credentials file or similar).