TEST: narrate and check in the claude-code-action job, the second job only publishes

This pull request splits the pull request explainer workflow in two. In the first job, Claude writes the presentation, runs the checks, and narrates it on the runner with Kokoro. In the second job, a fresh runner publishes that folder and posts the watch link. It's a test harness for a branch in another repository, so it isn't meant to merge.

The reason comes from the workflow's own comment. The Claude Code action removes the variables that mint the run's GitHub identity before Claude starts. That means Claude can write and fix its work, but it can't publish. So the identity lives in a separate job, the same split that PyPI trusted publishing and GitHub Pages use between building and publishing.

In job one, Claude has read access only. It fetches the spec, writes the slides and the context file, and reads the plan. Then it runs the pronunciation report and narrates, judges what the narration reports, and fixes problems before running both again. Because it narrates here, a bad pronunciation gets fixed by the author instead of shipping. The folder, audio included, goes up as an artifact.

Job two downloads the artifact and runs the action with a new presentation input. Only this job holds the permission to mint the identity, and it posts the comment. A new step reads the voice and speed from the sidecar file beside each audio clip, so publishing reuses the narration instead of making it again. If the slides disagree on voice or speed, or there's no audio, it warns and narrates the missing slides itself. Publishing also retries once after thirty seconds.

The diff carries more than the split. A new when input lets the model skip a dependency bump or a typo fix, and it only applies to automatic runs, never to a mention. A missing, expired, or out-of-quota key now ends green, with a note that names the secret to add. Private repositories publish as private instead of unlisted. Content problems at publish time become warnings, so the last step doesn't lose the run.

If you review this, start with the handoff: the workflow, the action file, and the step that reads the audio sidecars. The tests for judging, key refusal, and that step are the evidence. This walkthrough doesn't cover the large skill script change or the README rewrite. And again, this is a harness branch, so the thing to do is review, not merge.