Webhook git-auth: agent's code-interpreter tool has no git ("git: command not found") despite exec reporting exitCode=0

## Summary

In the webhook → Step Functions pipeline, the `agent-webhook-invoke-agent` git-auth prep step reports success (`exitCode=0`, "git/gh credential setup configured for github.com"), yet the harness agent's very first shell tool call fails with:

```
/bin/sh: line 1: git: command not found
```

So the agent cannot clone/commit/push/`gh pr create` even though the git-auth exec claims it succeeded — the `` prompt block tells the agent git is ready, but the tool it actually runs commands in has no `git` (and none of the seeded credentials).

## Evidence

Run `a2dd3d90-0332-4651-a71a-d734686634f2` (2026-07-14), Lambda log group `/aws/lambda/amplify-web-main-sandbox--agentwebhookinvokeagentl-2el0OYjb3Ur7`:

**git-auth Lambda log — exec succeeded:**
```
git/gh-auth exitCode=0
stdout:
git/gh credential setup configured for github.com
```

**Agent tool result — the agent's shell call failed:**
```json
{"toolResult": {"status": "success", "content": [{"text": "[{'type': 'text', 'text': '/bin/sh: line 1: git: command not found\r\n'}]"}], "toolUseId": "tooluse_Ujv2NQ8iZzuBNIimaT6nWB"}}
```

## Root cause (two different environments)

The setup and the agent's execution land in **different, isolated environments**:

1. **git-auth prep** ([`agent-webhook-invoke-agent/handler.ts:158`](web/amplify/functions/agent-webhook-invoke-agent/handler.ts#L158)) runs the git/gh setup via `InvokeAgentRuntimeCommand` (the harness-exec API), which executes in the **harness runtime session's shell**. AL2023 ships `git`, so `git config` succeeds there → `exitCode=0`.

2. **The agent's turn** is the native `bedrockagentcore:invokeHarness` task. When the `MyHarness` model runs a shell command, it does so through the built-in **`agentcore_code_interpreter`** tool — a **separate managed sandbox**, not the harness runtime container. That sandbox has no `git` on `$PATH` (hence `git: command not found`) and, critically, none of the `~/.git-credentials` / `gh` config the exec seeded.

The `git: command not found` shell (`/bin/sh: line 1:`) is the code-interpreter sandbox; the `git config`/`gh` setup ran in the harness runtime session. The two do not share a filesystem or `$PATH`.

This directly contradicts the assumption baked into [`docs/webhook-stepfunction-integration.md:167`](docs/webhook-stepfunction-integration.md#L167):

> (Verified empirically: a marker file written by an exec call is readable by the agent's code-interpreter tool in the same session.)

The current run shows that verification no longer holds (or the tool the model chose isn't the code interpreter that shared state). Either way, the `` promise in the prompt is false for this run.

## Impact

Any GitHub webhook run that needs git write access silently misleads the agent: it's told git/gh are authenticated, then hits `git: command not found` on the first call. PR-creation runs cannot succeed.

## Directions to investigate / fix

- Confirm which tool `MyHarness` actually invokes for shell commands (built-in `agentcore_code_interpreter` sandbox vs. the harness runtime shell) and whether that sandbox shares a filesystem/`$PATH` with the `InvokeAgentRuntimeCommand` session. The `exitCode=0` + `git: command not found` split strongly suggests they do **not**.
- If they don't share state, options:
- Seed git/gh **inside** the same environment the agent's tool uses (e.g. run setup + git operations through the same code-interpreter tool session, or install `git` into that sandbox and pass credentials there).
- Or route git operations to the harness runtime shell that *is* seeded (align the tool the agent uses with the exec target).
- Note the code-interpreter sandbox may also lack `git` entirely (managed image), so `gh`-style tarball install (already done for `gh`) may be needed for `git` too — or a different approach altogether.

## Related

- Builds on the harness-exec git-auth approach from the webhook/SFN integration (`docs/webhook-stepfunction-integration.md`).
- Contrast: the `AgUiHandler` runtime ([`agent/handler/agent.py:134`](agent/handler/agent.py#L134)) runs shell commands via a `subprocess`-backed `shell` tool in the **same** container as its `_prepare_workspace()`, so its git setup and git usage share state — which is exactly the property the harness path is missing.

### Secondary bug found while investigating

[`agent-webhook-invoke-agent/handler.ts`](web/amplify/functions/agent-webhook-invoke-agent/handler.ts) currently **does not compile** — a botched merge left two `export const handler` declarations and a `githubApiGet`/`buildGithubContextBlock` function nested inside the first `handler` body (which references an undefined `issueContext`). `tsc --noEmit` fails with `TS1005 '}' expected` at EOF (line 342). This needs fixing independently of the environment bug above (though the deployed Lambda that produced the log predates this broken state).

Start with web/amplify/functions/agent-webhook-invoke-agent/handler.ts around line 158 and compare the InvokeAgentRuntimeCommand target with the agentcore_code_interpreter behavior; read docs/webhook-stepfunction-integration.md around line 167 and agent/handler/agent.py around line 134. Run tsc --noEmit to confirm the independent handler compilation failure. Done means the agent's shell has git and seeded credentials in its actual environment, and the handler compiles.

Written by the indexing model from the issue text.