Add nested GITHUB_TOKEN permissions oracle

[lox]

Why

Clarify how GitHub scopes and issues GITHUB_TOKEN values for jobs expanded through nested reusable workflows, as discussed in #160.

What

Add a manually dispatched oracle with two nested reusable-workflow chains. The caller grants each chain a different permission, and a final job compares SHA-256 token fingerprints without exposing either token. GitHub's job setup logs show the effective permissions for each leaf job.

[buildsworth-bk-app]

No findings from this pass. This change exercises GITHUB_TOKEN issuance and permission propagation across nested reusable workflows, so it needs a human review before merge.

Want to dig deeper?

Paste this into your agent to explore the findings from this review's Buildkite build:

Download the buildsworth logs from build 14920, then answer my questions about the findings.

Install the reading-buildsworth-logs skill to run this.

About buildsworth

Model: gpt-5.6-sol with xhigh thinking.

How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.

Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. To let it approve, grant L2 approval by mentioning @buildsworth-bk (see L2 approval grant):

• L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
• L2 — Standard risk (new UI, additive API fields, refactors). Approved only with an L2 grant; otherwise comment-only.
• L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.