Install subprocess isolation dependencies: a hanging apt-get consumes the whole step timeout despite continue-on-error

## Summary

The `Install subprocess isolation dependencies` step in `action.yml` is declared best-effort (`continue-on-error: true`, "Best-effort: skips on non-Linux or when sudo/apt unavailable"), but a *hanging* `apt-get` — as opposed to a failing one — still kills the entire job. `continue-on-error` only tolerates a non-zero exit; it does nothing about a step that never exits. The step silently consumes the caller's whole `timeout-minutes` budget and Claude never runs.

https://github.com/anthropics/claude-code-action/blob/459ad358ae43fea66bfefd0a1f8d840b4b9791fb/action.yml#L225-L247

The retry loop does not help here for the same reason:

```bash
for i in 1 2 3; do
sudo apt-get update -qq && sudo apt-get install -y --no-install-recommends bubblewrap socat && break
echo "apt-get attempt $i failed, retrying..."
sleep 5
done
```

If a mirror accepts the connection and then stalls, `apt-get update` never returns, the `&&` never resolves, and the loop never reaches iteration 2. The retry covers the fast-failure case only, which is the less likely one on GitHub-hosted runners.

## Evidence

This is currently firing in `anthropics/claude-code`'s own `Claude Issue Triage` workflow, which uses `anthropics/claude-code-action@v1` with `allowed_non_write_users: "*"` (so the step is enabled) and `timeout-minutes: 5` on the action step.

Of the **last 100 runs** of that workflow, **10 failed, and all 10 are this exact signature** — the step burning the full 5-minute budget with zero output, not even the `apt-get attempt 1 failed, retrying...` line:

| run | `__run_3` duration |
| --- | --- |
| [32091441430](https://github.com/anthropics/claude-code/actions/runs/32091441430) | 309652 ms |
| [32090700246](https://github.com/anthropics/claude-code/actions/runs/32090700246) | 309812 ms |
| [32089934518](https://github.com/anthropics/claude-code/actions/runs/32089934518) | 309963 ms |
| [32089473766](https://github.com/anthropics/claude-code/actions/runs/32089473766) | 309488 ms |
| [32088750662](https://github.com/anthropics/claude-code/actions/runs/32088750662) | 309338 ms |
| [32088382552](https://github.com/anthropics/claude-code/actions/runs/32088382552) | 309644 ms |
| [32088203619](https://github.com/anthropics/claude-code/actions/runs/32088203619) | 310028 ms |
| [32087190931](https://github.com/anthropics/claude-code/actions/runs/32087190931) | 310391 ms |
| [32086961767](https://github.com/anthropics/claude-code/actions/runs/32086961767) | 309849 ms |
| [32084523998](https://github.com/anthropics/claude-code/actions/runs/32084523998) | 310061 ms |

Log excerpt from [32088203619](https://github.com/anthropics/claude-code/actions/runs/32088203619):

```
01:26:19.5357Z start-action display=Install subprocess isolation dependencies;id=__anthropics_claude-code-action.__run_3
01:26:19.5432Z ##[endgroup]
(no output for 310 seconds)
01:31:29.5634Z ##[error]The action has timed out.
01:31:29.5640Z end-action id=...__run_3;outcome=failure;conclusion=success;duration_ms=310028
```

Every subsequent step in the composite action is then reported as `The action has timed out.`, which makes the run look like seven distinct failures when there is one cause. The bun install of the agent SDK completed normally 1 s earlier, so general network egress on the runner was fine — it is specific to the apt mirror.

## Impact

Beyond the lost run, the failure notification lands on whoever triggered it. `claude-issue-triage.yml` runs `on: issue_comment`, so an external commenter with no visibility into or control over the workflow gets mailed a "workflow failed" notice for infrastructure they cannot touch. At a 10% flake rate on a busy public issue tracker, that is a fair amount of noise pushed onto third parties. (I hit this by commenting on anthropics/claude-code#87487.)

## Suggested fix

Wrap the apt-get calls so a hang degrades into the failure the retry loop and `continue-on-error` are already designed to absorb:

```bash
if command -v apt-get >/dev/null && command -v sudo >/dev/null; then
for i in 1 2 3; do
timeout 60 sudo apt-get update -qq \
&& timeout 120 sudo apt-get install -y --no-install-recommends bubblewrap socat \
&& break
echo "apt-get attempt $i failed or timed out, retrying..."
sleep 5
done
fi
```

Worst case then becomes ~9 minutes of retries, so pairing it with an explicit `timeout-minutes:` on the step itself (e.g. `timeout-minutes: 4`) would bound it regardless — with `continue-on-error: true` already set, a step-level timeout is non-fatal and the job proceeds to run Claude unsandboxed, which is the documented best-effort behaviour.

Related but distinct: #1420 covers *when* this step runs (gating on `allowed_non_write_users`), not its robustness once it does.