Reduce privileged-token exposure in fix_linting.yml

The @nf-core-bot fix linting workflow in the pipeline template checks out a pull request with gh pr checkout and then runs prek (which executes hook configuration from that same pull request) while the privileged nf_core_bot_auth_token is already present in the job's git credential store from the initial checkout step. Since prek's hook config is part of the untrusted PR content, that job ends up running PR-controlled tooling in the same context as a write-scoped token.

This is routine GitHub Actions hygiene to tighten — the general pattern (separating the job that runs untrusted PR code from the job that holds a privileged token) is the same approach already used for the PR-comment workflows (#4342). I've put together a PR that applies it here too, tested by rendering the template and running actionlint against the output.

While in there, I also tightened awsfulltest.yml's "second approval" trigger, which currently trusts github.event.review.state == 'approved' without checking that the approving reviewer actually holds write access — anyone can leave an "Approved" review on a public repo, so this should verify permission level via the API rather than trusting the review state alone.

Start with the pipeline template's fix_linting.yml workflow and inspect awsfulltest.yml's second-approval trigger. Render the template and run actionlint as described; done means untrusted pull-request hooks no longer share the privileged token context and approval handling verifies reviewer write access.