ci: run yamllint on pull requests

[nielspardon]

yamllint is configured as a pre-commit hook but is not enforced in CI, so line-length and bracket violations have accumulated on main and committing a touched workflow file requires git commit --no-verify. This adds a CI check and brings the existing workflows into compliance so the check passes.

Enforce in CI

• Add a Lint YAML job to the PR build workflow that runs the yamllint pre-commit hook against all files. It reuses the pinned config and version from .pre-commit-config.yaml (.yamllint.yaml, yamllint v1.33.0), keeping CI and local checks in lockstep.

Fix existing violations

• Rename step (release.yml, pr.yml): use a step working-directory instead of repeating the long isthmus-cli/build/native/nativeCompile/ path twice in mv (also drops the unused value= capture).
• Release-bot email (release.yml): derive the email once as an output of the bot-user-id step and reference it, removing the two duplicated long GIT_AUTHOR_EMAIL / GIT_COMMITTER_EMAIL lines.
• pr_title.yaml: scope a # yamllint disable/enable rule:line-length pair around the github-script step — its long lines are prose inside a template literal, where wrapping would alter the rendered PR comment. The rest of the file stays checked.

No behavior change to the workflows. Verified pre-commit run yamllint --all-files passes.

🤖 Generated with AI

[benbellick]

These changes look reasonable to me, but I am nervous about things which alter the release process. Lets make sure to monitor the next release and see if things go through without a problem.

[benbellick]

I think alternatively we can do:

     - name: Configure release bot email
        run: |
          slug="${{ steps.app-token.outputs.app-slug }}"
          user_id="$(gh api "/users/${slug}[bot]" --jq .id)"
          email="${user_id}+${slug}[bot]@users.noreply.github.com"
          {
            echo "GIT_AUTHOR_EMAIL=${email}"
            echo "GIT_COMMITTER_EMAIL=${email}"
          } >> "$GITHUB_ENV"
        env:
          GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}
      - name: Run semantic-release
        run: ./ci/release/run.sh
        env:
          GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}
          SIGNING_KEY_ID: ${{ secrets.SIGNING_KEY_ID }}
          SIGNING_PASSWORD: ${{ secrets.SIGNING_PASSWORD }}
          SIGNING_KEY: ${{ secrets.SIGNING_KEY }}
          MAVENCENTRAL_USERNAME: ${{ secrets.MAVEN_CENTRAL_USER }}
          MAVENCENTRAL_PASSWORD: ${{ secrets.MAVEN_CENTRAL_KEY }}

where the change is to use GITHUB_ENV in place of GITHUB_OUTPUT.

I'm fine with either though.

[nielspardon]

Thanks for the suggestion. It feels to me like using GITHUB_OUTPUT limits the scope better since GITHUB_ENV would set the environment for all subsequent steps while for outputs we set the environment on each step to be derived from the outputs which gives us better lineage of where the environment variables of a step come from. I merged with the outputs approach for now.