Action fails on pull_request events when the PR's base branch was deleted, as happens when a merged PR stack's branches are auto-deleted

**Describe the bug**

On `pull_request` events the action restores trusted configuration files from the PR's base branch before running any prompt. When that branch no longer exists, the `git fetch` fails and the whole action fails. This is a robustness report, not a security report.

- The restore branch comes from `payload.pull_request.base.ref`, with no input override on `pull_request` events: https://github.com/anthropics/claude-code-action/blob/a60f3e1db3edbceed2b1e6c6a9d34c36b8a15eba/src/entrypoints/run.ts#L263-L276
- The fetch of that branch has no failure handling: https://github.com/anthropics/claude-code-action/blob/a60f3e1db3edbceed2b1e6c6a9d34c36b8a15eba/src/github/operations/restore-config.ts#L310-L323
- The per-path restore below it already treats failure as a safe outcome: https://github.com/anthropics/claude-code-action/blob/a60f3e1db3edbceed2b1e6c6a9d34c36b8a15eba/src/github/operations/restore-config.ts#L325-L333

`validateBranchName` does not reject this case. Our logs show the run reaching the fetch, so the name is well formed and the branch is simply gone.

How we hit it: GitHub's stacked pull requests feature, in public preview since July 30, 2026. GitHub documents that workflows trigger as if each PR in the stack targets the base of the stack, so a `branches: [main]` filter matches every PR in a merged stack (https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests). Every PR in a stack except the bottom one targets the head branch of the PR below it. Our repository has "Automatically delete head branches" enabled, so those branches were deleted when the stack merged. In one such failure, the PR merged at 2026-08-27T20:59:32Z, the workflow run was created at 20:59:36Z, and at 21:00:20Z the action failed with `fatal: couldn't find remote ref ` from `git fetch origin --depth=1 --no-recurse-submodules`.

**To Reproduce**

We hit this in production through stacked PR merges, and separately validated these steps on August 28, 2026 in a scratch repository against `anthropics/claude-code-action@v1`, which resolved to `a60f3e1db3e`, current main:

1. Add the workflow below to a repository.
2. Create a branch `temp-base`, create a branch `feature` off it with any commit, and open a PR from `feature` into `temp-base`.
3. Close the PR, then immediately delete `temp-base`. Timing is not tight. In our validation run the PR closed at 2026-08-28T15:50:47Z, the workflow run was created at 15:50:50Z, and the action did not attempt the fetch until 15:51:13Z, because it installs the Claude Code CLI first.
4. The action step fails:

```
2026-08-28T15:51:13.6537016Z Restoring .claude, .mcp.json, .claude.json, .gitmodules, .ripgreprc, CLAUDE.md, CLAUDE.local.md, .husky from origin/temp-base (PR head is untrusted)
2026-08-28T15:51:13.9090165Z fatal: couldn't find remote ref temp-base
2026-08-28T15:51:13.9137733Z ##[error]Action failed with error: Command failed: git fetch origin temp-base --depth=1 --no-recurse-submodules
2026-08-28T15:51:13.9198886Z ##[error]Process completed with exit code 1.
```

A placeholder `ANTHROPIC_API_KEY` value is sufficient to reproduce, because the failure happens before any API call. Our validation run used one.

**Expected behavior**

A missing base branch ends the restore without failing the run. For a merged PR, the repository default branch still exists as a trusted restore source, and falling back to it keeps both the run and the restored configuration. If the fix is instead to swallow the fetch error and leave the sensitive paths deleted, which is what https://github.com/anthropics/claude-code-action/pull/1658 does for a different fetch failure, these runs would silently lose `.claude/` from the checkout, because the paths are deleted before the fetch runs. We would prefer the default-branch fallback.

**Screenshots**

Not applicable.

**Workflow yml file**

Our production workflow is in a private repository. This is the workflow the validation run above used:

```yaml
name: Claude on merged PRs
on:
pull_request:
types: [closed]
permissions:
contents: read
jobs:
claude:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
github_token: ${{ github.token }}
prompt: Say hello.
```

**API Provider**

- [x] Anthropic First-Party API (default)
- [x] AWS Bedrock
- [ ] GCP Vertex

Production failures were on Bedrock. The validation repro used the default provider path.

**Additional context**

Production failures were on v1.0.194, pinned to `459ad358ae43`; the validation repro failed identically at `a60f3e1db3e`. In the two weeks before August 28, 2026 we had two stack merges, of four and two pull requests, and in both stacks every pull request above the bottom one failed this way. We searched this repository's issues and pull requests and found no existing report of this; the closest is #1658.