Server-info state collides across workflow re-run attempts

Summary

codex-action keys its Responses proxy server-info file only by github.run_id:

$CODEX_HOME/$GITHUB_RUN_ID.json

GitHub keeps run_id stable when a workflow run is re-run and increments github.run_attempt. On a persistent/self-hosted runner, a later attempt can therefore reuse or collide with state created by the previous attempt.

Reproduction

1. Run a workflow using openai/codex-action on a persistent self-hosted runner.
2. Let the action create $CODEX_HOME/<run_id>.json.
3. Re-run the same workflow run from GitHub.
4. The new attempt has the same github.run_id, so the action derives the same server-info path.

If the prior file remains, the new attempt can treat old proxy metadata as current. If a previous background proxy is still alive, this is particularly confusing because the liveness check can succeed even though the process belongs to a different workflow attempt and may have been started with different credentials or endpoint configuration.

Expected behavior

Proxy state should be shared within one workflow attempt but isolated from later re-run attempts.

Suggested fix

Use a stable per-attempt key such as:

<github.run_id>-<github.run_attempt>

where the action currently passes/uses github.run_id for server-info state.

This preserves reuse across repeated action calls inside the same attempt while preventing collisions with previous attempts.

Impact

This is lifecycle isolation for persistent runners. GitHub-hosted runners usually get fresh filesystems, but self-hosted runners can retain $CODEX_HOME across attempts.

Search the action for where github.run_id is passed to or used for Responses proxy server-info state. Update the key to include github.run_attempt, then verify that repeated calls within one attempt still share state while later workflow attempts use an isolated path.