Agent's Bash/Read tools see a stale working tree that doesn't match the checked-out HEAD (issue_comment trigger)

## Summary

When `claude-code-action` is triggered via an `issue_comment` event (a PR comment
mentioning `@claude`), the git checkout itself ends up on the correct commit — but the
agent's own Bash/Read tool calls see a **different, stale filesystem state** that doesn't
match that commit. `git branch`/`git rev-parse HEAD` report the right ref, yet `ls`/`Read`
on tracked files return content that matches an older commit, and `git status` shows
those files as uncommitted deletions/modifications relative to HEAD — even though nothing
in the job actually modified them.

This is a different bug from #1266/#1295 (the Bun `tsconfig.json` "directory mismatch"
warning) — that one is cosmetic and doesn't affect file content; this one does.

## Environment

- `claude-code-action@v1`
- Trigger: `issue_comment`, `types: [created]`
- `actions/checkout@v4`, `fetch-depth: 1`, explicit `ref: ` resolved via
`gh api` before checkout (added specifically to fix a separate, related bug — see below)
- `runs-on: ubuntu-latest`
- Private repository (happy to provide access or redacted logs on request)

## Reproduction

1. PR with a branch whose tree differs substantially from the checkout's resolved
branch's previous state (in our case, dozens of files added between the workflow's
resolved branch and an earlier commit).
2. Comment `@claude` on that PR, asking it to run:
```
git branch --show-current
git rev-parse HEAD
ls
git status
```
3. Compare the reported output against `git show HEAD:` for the same commit,
fetched independently (e.g. via `gh api` or a local clone).

## Observed

From a run against the reproduction above:

- Checkout step: `git checkout --progress --force -B refs/remotes/origin/`
— correct branch.
- The action's own internal diff-preparation step computes real, correct blob SHAs for
every changed file (e.g. `some/rule/file.md (ADDED) +117/-0 SHA: ` —
matches `git show HEAD:some/rule/file.md`'s hash exactly).
- Yet the agent's own tool call in the same run reports:
```
$ git branch --show-current

$ git rev-parse HEAD

$ ls some/rule/dir/
only-one-file.md
```
Several files known to be present in that commit (confirmed via `git show
:some/rule/dir/`) are absent from the agent's own `ls`. `git status` inside
the agent's session additionally reports those files as `deleted` / `modified`,
uncommitted, relative to that same HEAD.

## Expected

The agent's Bash/Read tool calls should observe the same filesystem state that the
action's own checkout and diff-preparation logic already correctly established.

## Additional notes

- This does NOT reproduce on `pull_request: [opened, reopened]`-triggered runs of the
same repo — only on `issue_comment`.
- We initially suspected this was caused by GitHub defaulting `issue_comment` checkouts
to the base branch (a separate, known issue — anthropics/claude-code-action#46). We
fixed that independently by resolving the head ref via the API before checkout. This
bug persists after that fix, with checkout confirmed correct via the logs above — so
it's a distinct root cause, likely in how the agent's execution sandbox mounts/
snapshots the working tree rather than in the checkout step itself.
- Happy to share redacted run logs or attempt a minimal public reproduction if useful.