Dead code from the v1.0 single-entrypoint refactor: orphaned src/entrypoints/prepare.ts and three unused exports

## Summary

The v1.0 consolidation onto a single `run.ts` entrypoint left behind an orphaned parallel copy of the prepare phase plus three unreferenced exports. The `prepare.ts` orphan is the one that matters: it is a plausible-looking duplicate of live logic, so a contributor can fix a bug in it and observe no effect.

`CLAUDE.md` documents the intended architecture:

> Single entrypoint: `src/entrypoints/run.ts` orchestrates everything — prepare (auth, permissions, trigger check, branch/comment creation), install Claude Code CLI, execute Claude via `base-action/` functions ... then cleanup

## 1. `src/entrypoints/prepare.ts` — orphaned duplicate of the prepare phase

[103 lines](https://github.com/anthropics/claude-code-action/blob/d721746d683d812e669ce117cebe55a85fbd9c3e/src/entrypoints/prepare.ts), referenced by nothing:

```console
$ grep -rn "entrypoints/prepare" --include="*.ts" --include="*.yml" src action.yml test base-action
(no output)
```

`action.yml` invokes only `src/entrypoints/run.ts`, `src/entrypoints/cleanup-ssh-signing.ts`, and `src/entrypoints/post-buffered-inline-comments.ts`. Nothing imports `prepare.ts`, and no test references it.

It imports and re-sequences the same modules `run.ts` uses — `setupGitHubToken`, `checkWritePermissions`, `parseGitHubContext`, `detectMode`, `prepareTagMode`, `prepareAgentMode`, `checkContainsTrigger`, `collectActionInputsPresence` — so it reads as a live alternative entrypoint. That is the hazard: it will drift from `run.ts` silently, and it is an inviting place to "fix" a prepare-phase bug with no runtime effect.

## 2. `updateTrackingComment` — no callers

[`src/github/operations/comments/update-with-branch.ts`](https://github.com/anthropics/claude-code-action/blob/d721746d683d812e669ce117cebe55a85fbd9c3e/src/github/operations/comments/update-with-branch.ts) (57 lines) exports one function:

```console
$ grep -rn "updateTrackingComment" --include="*.ts" src test | grep -v "update-with-branch.ts:"
(no output)
```

The branch-link-into-tracking-comment behaviour it implements is now handled by `updateCommentLink` in `src/entrypoints/update-comment-link.ts` via `checkAndCommitOrDeleteBranch`.

## 3. `checkTriggerAction` — no callers

[`src/github/validation/trigger.ts#L151-L155`](https://github.com/anthropics/claude-code-action/blob/d721746d683d812e669ce117cebe55a85fbd9c3e/src/github/validation/trigger.ts#L151-L155):

```console
$ grep -rn "checkTriggerAction" --include="*.ts" src test | grep -v "trigger.ts:"
(no output)
```

`run.ts` calls `checkContainsTrigger` directly. The thin wrapper that additionally sets a `contains_trigger` output is unused, and no `contains_trigger` output is declared in `action.yml`.

## 4. Dead env exports the code already flags

[`src/create-prompt/index.ts#L984-L997`](https://github.com/anthropics/claude-code-action/blob/d721746d683d812e669ce117cebe55a85fbd9c3e/src/create-prompt/index.ts#L984-L997) — the comment is in the source:

```ts
// NOTE: these env var exports are dead — nothing reads ALLOWED_TOOLS / DISALLOWED_TOOLS.
// The live path is modes/tag/index.ts which builds --allowedTools into claudeArgs directly.
// Kept only so the H1 report's pointed-to file stays in sync with the live fix.
const hasActionsReadPermission = false;

const allAllowedTools = buildAllowedToolsString(...);
const allDisallowedTools = buildDisallowedToolsString([], []);

core.exportVariable("ALLOWED_TOOLS", allAllowedTools);
core.exportVariable("DISALLOWED_TOOLS", allDisallowedTools);
```

Confirmed — nothing reads either variable:

```console
$ grep -rn "ALLOWED_TOOLS\|DISALLOWED_TOOLS" --include="*.ts" --include="*.yml" src base-action action.yml \
| grep -v "INPUT_ALLOWED\|INPUT_DISALLOWED"
src/modes/agent/parse-tools.ts:5:const ALLOWED_TOOLS_FLAGS = new Set(["allowedTools", "allowed-tools"]);
src/modes/agent/parse-tools.ts:64: if (!ALLOWED_TOOLS_FLAGS.has(flag)) continue;
src/create-prompt/index.ts:34:const BASE_ALLOWED_TOOLS = ["Glob", "Grep", "LS", "Read"];
src/create-prompt/index.ts:42: let baseTools = [...BASE_ALLOWED_TOOLS];
src/create-prompt/index.ts:984: // NOTE: these env var exports are dead ...
src/create-prompt/index.ts:996: core.exportVariable("ALLOWED_TOOLS", allAllowedTools);
src/create-prompt/index.ts:997: core.exportVariable("DISALLOWED_TOOLS", allDisallowedTools);
```

The only remaining references are the definitions themselves and an unrelated constant.

## Note on item 4

The trailing comment — *"Kept only so the H1 report's pointed-to file stays in sync with the live fix"* — suggests this block was retained deliberately so a security report's referenced file still shows the corresponding change. If that reason still holds, this item should stay as-is; I've included it for completeness rather than proposing removal. Maintainers are better placed to judge.

Removing it would also require updating `test/create-prompt.test.ts`, which is currently the only consumer of `buildAllowedToolsString` and `buildDisallowedToolsString`.

## Suggested fix

Items 1–3 are safe deletions. I'd propose them as one PR, or as three commits in one PR, whichever is easier to review — and leaving item 4 alone unless a maintainer confirms the H1 constraint has lapsed.

Before opening anything, I'd like confirmation on one point: is `src/entrypoints/prepare.ts` genuinely dead, or is it retained intentionally (for a documented manual invocation, or for a downstream consumer outside this repo)? I did not want to send a deletion PR against something being kept on purpose.

## Environment

- Repository at `d721746d683d812e669ce117cebe55a85fbd9c3e` (`main`)