Authenticate git without writing the installation token into .git/config, independent of allowed_non_write_users

`replaceCheckoutCredentials` in `src/github/operations/git-config.ts` rewrites the `origin` remote URL to `https://x-access-token:@github.com//.git` in every mode, unless `ALLOWED_NON_WRITE_USERS` is set — only then does it switch to a credential helper (added in #1132) and leave `.git/config` token-free. Please make the token-free path selectable on its own, independent of `allowed_non_write_users`.

**Why.** Workflows that review untrusted code (fork PR heads, external contributors' PRs) can already keep credentials away from that code: `actions/checkout` with `persist-credentials: false` keeps the job token out of `.git/config`, and Claude Code's `sandbox.credentials.envVars` `deny` entries hide token env vars from sandboxed Bash. The action's prepare step then writes its **own** installation token back into `$GITHUB_WORKSPACE/.git/config`. Anything the agent runs in the workspace — a `pyproject.toml` build backend during `pip install -e .`, a test module collected by pytest — can read that file, and the token carries the job's permissions for the duration of the step. Today the only way to get the credential-helper path is `allowed_non_write_users`, which changes *who may trigger runs* — a much bigger security decision than *how git authenticates*.

**Ask.** Any of:

1. A boolean input (e.g. `git_credential_helper: true`) selecting the helper path regardless of `allowed_non_write_users`.
2. Make the helper the default and keep URL embedding behind an opt-in.
3. Scope auth to the action's own git calls (`GIT_CONFIG_COUNT`/`GIT_CONFIG_KEY_n`/`GIT_CONFIG_VALUE_n`, or `-c http.extraheader=…` on those child processes) and leave the on-disk config untouched.

Note the interaction from #1139: a helper reading `$GH_TOKEN` at auth time fails when the subprocess env is scrubbed, or when a sandbox `credentials.envVars` `deny` for `GH_TOKEN` is in effect; a helper reading from a 0600 file outside the workspace (`RUNNER_TEMP`/`GITHUB_ACTION_PATH`), or option 3, avoids that.

**Current workaround.** A `sandbox.credentials.files` entry (Claude Code ≥ 2.1.221):

```json
{ "path": "/.git/config", "mode": "mask", "extract": "x-access-token:([^@]+)@", "onExtractNoMatch": "deny" }
```

Sandboxed commands see a sentinel and git still parses its config; if the URL shape changes the file becomes unreadable rather than exposed. This protects only sandboxed Bash and depends on the exact URL shape — an action-side option would be the proper fix.

**Related, not duplicates.** #1509 / #1534 are about the *revoked* token being left in the URL after the run (cleanup); #1510 / #1721 are about removing *checkout's* credential; #1236 / #1711 / #1559 are about `persist-credentials: false` breaking the action's own fetches. This issue is about the action's token being on disk in the workspace *during* the run, in the default auth path.

Context: meridianlabs-ai/agents#70 (the workaround is implemented in meridianlabs-ai/agents#72).