Adapt Build/Linting pipeline to avoid unlinted code on main/master

[jamand]

What happened:

In this PR I introduced a linting issue which was not detected by build / sast-lint / run-linter. All PR Checks were green.

Only in the summary of the run you can see a warning:

Warning: Checked out target-repository's contents, as pullrequest author is not trusted

The linter ran on master (fallback on trusted-checkout).

What you expected to happen:

I would expect the linting pipeline to fail.

How to reproduce it (as minimally and precisely as possible):

1. Create a fork of the repository under an untrusted org (as a non-OWNER).
2. Create a PR with a linting issue.
3. The linter should show 0 issues (as is falls back to checking master).

https://github.com/gardener/machine-controller-manager-provider-openstack/actions/runs/18780246304

Additional info:

Check conversation on Slack:

So as you assumed, since you were (/are) not considered to be "trustworthy enough",
your pullrequest-validation-pipelineruns fell back to using target-repository's
source code, which explains why mentioned linter-error was not visible.
there are different options to improve on this:
- switch to using "label-based triggering" (see linked documentation); with that,
also pullrequests from untrusted forks will be checked, as pullrequest-author(s) would expect.
however, only after (manual) labelling from codeowners
- switch to on.pull_request as trigger. if doing so, pipeline-checks will run as
expected, but pipelines will be unprivileged, hence not be able (and not even attempt to)
publish built images, helmcharts, etc.
- combination of the two: split pipeline into two parts
(I think gardener-dashboard colleagues did this)

We should ensure that no unlinted code can be merged to the master branch based on the docs. Gardener Dashboard seems to use a mixed apprach of the approaches mentioned on Slack.