docs: plan signed branch updates for signature-enforcing repos

[robinbowes]

Adds docs/plans/signed-branch-updates/README.md.

Every commit Last Light creates with git in a sandbox is unsigned, and 22 of the yo61 repos enforce required_signatures on main. On those repos a fix run that merges the base branch does not unblock the PR — it blocks it permanently, because the rule is evaluated over every commit reachable in the PR, not just the head.

The case

yo61/go-udap#185 sat at mergeStateStatus: BLOCKED with all eight required checks green, mergeable: MERGEABLE and zero required approvals. The sole blocker was merge commit 747b1c08:

verification: { verified: false, reason: "unsigned" }
author/committer: yo61-lastlight[bot] <yo61-lastlight[bot]@users.noreply.github.com>

Dependabot's own commit on the same branch was verified: true — anything pushed through GitHub's API is web-flow signed automatically. Enabling auto-merge (which we did, at 15:04:38Z) could never have fired.

Recovery required @dependabot recreate, which discarded the branch, threw away a green CI run, and produced a red one — the regenerated lockfile pulled in transitive deps inside pnpm's 24h minimumReleaseAge window.

Why the App token doesn't help

The token authenticates the push; a signing key signs the commit object. A sandbox has the first and not the second, and no amount of write permission changes that. Last Light configures signing nowhere — the only gpgsign settings in this repo are tag.gpgsign for releases.

The merge itself (workflows/prompts/dependabot-ci-fix.md:71) is correct and deliberate — it makes a behind PR current and regenerates lockfiles on conflict. The defect is the mechanism, not the intent.

What the plan proposes

• PUT /repos/{owner}/{repo}/pulls/{number}/update-branch instead of a sandbox git merge whenever the goal is only "make this PR current". GitHub merges server-side, so the commit is committed by GitHub <noreply@github.com> and web-flow signed. No key management.
• POST .../actions/runs/{run_id}/rerun-failed-jobs where the goal is only to re-run CI after a transient failure — creates no commit at all. That was the actual need on go-udap#185.
• Documents the gap neither closes: update-branch can't resolve conflicts, so dirty PRs still need a sandbox commit, still unsigned, still unlandable on those 22 repos.
• Leaves "should Last Light hold a signing key?" as an explicit open question rather than assuming it.

Filed as a new plan directory rather than a phase of stuck-pr-recovery, since that plan's phases are all complete with execution notes dated 2 Aug. It is the mirror image of that plan: there, recovery made stuck PRs survivable; here, the recovery mechanism is itself what gets the PR stuck.

Note on measuring blast radius

The 22-repo figure is from live GET /repos/{owner}/{repo}/rules/branches/main calls. Do not infer it from github-repos Terraform data — data/yo61/go-udap.yaml reads required_signatures: false, which is the setting for that repo's own additional_rulesets block; the actual rule arrives via builtin_ruleset_names: [default_branch]. The config file states the opposite of the effective policy.

🤖 Generated with Claude Code

[robinbowes]

Superseded by nearform#268. yo61/lastlight is a fork, so committing a new plan directory here would diverge it from upstream and risk riding along in any future upstream PR. Upstream's own pattern is plans in docs/plans/ with discrete actionable work filed on its tracker, so the issue is the right home.