ci: grant pull-requests read permission to PR title workflow

[Dor-bl]

Problem

The Conventional Commits workflow fails with startup_failure before any job is scheduled — for example run 33952074548 on #1:

The nested job 'conventional-pr-check' is requesting 'pull-requests: read', but is only allowed 'pull-requests: none'.

.github/workflows/pr-title.yml calls the reusable workflow appium/appium-workflows/.github/workflows/pr-title.yml@main, whose conventional-pr-check job declares permissions: pull-requests: read (needed by amannn/action-semantic-pull-request@v6).

A called workflow can never hold more permissions than its caller. This caller declared no permissions: block, so it inherited this repository's restricted default GITHUB_TOKEN scopes (pull-requests: none), and GitHub rejects the run at parse time.

Change

Declare the minimum required scopes explicitly on the caller:

permissions:
  contents: read
  pull-requests: read

This keeps least privilege and makes the workflow work regardless of the repository's Default workflow permissions setting. lock-update.yml and publish.yml already set their permissions explicitly; pr-title.yml was the only workflow relying on the inherited default.

Verification

• YAML parses cleanly.
• This PR itself exercises the fix: the Conventional Commits check runs against this branch's workflow file, so a green check here confirms the resolution.
• Note that docs: add usage examples to screen recording methods #1 will stay red until this lands on master and that branch picks up the change — workflow definitions are read from the run's head commit.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01KeCzb8yu8DPk9wa292irps

---

Generated by Claude Code