Update 8hobbies/workflows digest to a18577b

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
8hobbies/workflows	action	digest	951751b -> a18577b

---

Configuration

📅 Schedule: Branch creation - "on Sunday" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

To fix the problem, add a permissions block to the workflow to explicitly limit the permissions granted to the GITHUB_TOKEN. Since this is a lint job, it likely only needs read access to the repository contents. The best way to fix this is to add a permissions block at the root level of the workflow (before jobs:), specifying contents: read. This ensures that all jobs in the workflow, including those using reusable workflows, will have only the minimum required permissions. Edit .github/workflows/lint.yml to insert the following block after the name: line and before the on: block:

permissions:
  contents: read

No additional imports or definitions are needed.

To fix the problem, add a permissions block at the top level of the workflow file (just after the name: or before/after the on: block). This block should specify the minimal permissions required for the workflow to function. Since this workflow only delegates to a reusable workflow and does not appear to require any write access, the safest minimal starting point is contents: read. If the reusable workflow requires more, you can adjust accordingly, but starting with contents: read is recommended. The change should be made in .github/workflows/publish-dry-run.yml by inserting the permissions: block after the name: line.

To fix the problem, add a permissions block to the workflow file. This can be done at the top level (applies to all jobs) or at the job level (applies to a specific job). Since this workflow only defines a single job (test), either location is acceptable, but adding it at the top level is clearer and future-proof. The minimal safe starting point is permissions: {} (no permissions), but if the reusable workflow requires specific permissions, you should grant only those. Since we do not know the exact requirements of the called workflow, the best fix is to add permissions: {} at the top level, just after the name: key and before on:.