Warn when sandbox_branch makes every github: directive a no-op

[potiuk]

The problem

docs/testing-a-change.md tells you to put the .asf.yaml under test on a
test/pr-<NNN> branch and pass that as sandbox_branch. That skips every directive
under github: — which is most of what the sandbox exists to test — and the run exits
0 anyway. The workflow reports a pass having applied nothing.

I hit this while testing seven open PRs and lost a while to it, which is the only reason
I noticed: the log line is easy to miss among the noop chatter, and nothing else about
the run looks wrong.

[github] Saw GitHub meta-data in .asf.yaml, but not in default branch of repository, not updating...

The gate is in feature/github/__init__.py,
which returns early unless the branch being processed is the repository's default branch.
Repository.default_branch derives that from a HEAD file in the directory it is handed —
present in the bare repositories the parser sees in production, absent from the working
tree actions/checkout produces — so it falls back to the DEFAULT_BRANCH constant,
main. A sandbox run therefore applies github: settings only when sandbox_branch is
literally main, regardless of what the sandbox repository's own default branch is called.

Reproducible with no network and no token:

$ asfyaml-run --repo .../infrastructure-asfyaml-sandbox --org me --branch test/pr-111 --noop --token dummy
[github] Saw GitHub meta-data in .asf.yaml, but not in default branch of repository, not updating...

The docs also state the opposite of this outright, under "Branch-scoped and repo-scoped
settings behave differently":

Repository metadata under github: is not branch-scoped: it applies to the whole repo
no matter which branch it was read from.

What this changes

Docs. Step 2 puts the configuration on the sandbox's main and says why; step 3's
table and step 6's reset are rewritten around a baseline branch; the incorrect section
above is replaced with an accurate one that names the file, the constant and the fallback.

Workflow. A warning annotation and a block in the run summary when sandbox_branch
is not main, so a run that cannot prove anything says so where the result is read
rather than only in the log.

Skill. One line, so .claude/skills/sandbox-test/SKILL.md (from #133) matches.

What this deliberately does not change

The parser. Making default_branch fall back to the checked-out branch would fix the
symptom, but it would also let a feature branch apply repository settings whenever the
parser is pointed at a working tree instead of a bare repo — a safety property worth
keeping. If the gate itself should be relaxed for testing, that deserves its own
discussion; this PR makes the existing behaviour visible instead of quietly wrong.

Testing

• Both edited run: blocks shell-syntax checked, and the resolve step executed directly
  with the workflow's own env: sandbox_branch=main is silent and sets
  sandbox_branch_warning=no; sandbox_branch=test/pr-42 emits the annotation and sets
  yes.
• The whole workflow file parses as YAML and every run: block passes bash -n.
• poetry run pytest — 145 passed. poetry run pre-commit run --all-files — green.
• The underlying behaviour was confirmed against a live sandbox repo while testing Add regex pattern support for branch protection rules #81,
  Add GitHub immutable releases #84, Fix: prevent_self_review breaks all environment creation via .asf.yaml #101, Add GitHub pull request creation cap support #111, Support changing or removing Jira autolinks #116, feat(github): add merge_queue convenience syntax for rulesets #119, Add restrict_update convenience key to prevent tags from being moved #120 and Add github.code_scanning for CodeQL default setup #122: configurations on main applied, the same
  configurations on a test/ branch did not.

No parser code changes, so there is nothing here for the sandbox workflow itself to test.

🤖 Generated with Claude Code