execute_bash command-channel integrity failure: stdout/receipt marker mismatch

### Checks

- [x] I have searched [github.com/aws/amazon-q-developer-cli/issues](https://github.com/aws/amazon-q-developer-cli/issues?q=) and there are no duplicates of my issue
- [x] I have run `q doctor` in the affected terminal session
- [x] I have run `q restart` and replicated the issue again

### Operating system

macOS 12.7.6 (21H1320)

### Expected behaviour

execute_bash should preserve command/result pairing. The stdout, exit code, and any receipt file read immediately afterward should correspond to the command just issued, not a previous command in the session.

### Actual behaviour

Subject: execute_bash / command receipt channel mismatch causing unsafe mutation state

I’m seeing recurring reliability failures in Kiro execute_bash where command output markers and receipt files do not consistently correspond to the command just issued.

Impact:
- Kiro cannot safely perform git add/git commit or other mutation commands.
- We have had to stop all mutation workflows when canary checks fail.
- Read-only commands can sometimes be verified through file-backed receipts, but mutation workflows are not trustworthy when the channel mismatch appears.

Observed behavior:
- A command is issued with a unique marker.
- The next observed stdout/receipt sometimes shows a marker from a prior command.
- File-backed receipt verification has also shown inconsistent command/result pairing.
- This happens intermittently across sessions, not just one command.
- Because of this, Kiro cannot reliably prove:
command issued = command whose output was read
stdout marker = correct receipt
receipt file = current command result

Example consequence:
During Git admission, Kiro correctly stopped before staging/committing because canary C failed. Manual Terminal commit by the user was required instead.

Current workaround:
- Kiro performs read-only audits and prepares exact commands.
- User runs Git mutations manually in Terminal.
- Kiro performs read-only reconciliation afterward.
- We treat Kiro execute_bash as READ_ONLY_TRUSTED_WITH_RECEIPTS but NOT trusted for mutation when canaries fail.

Requested help:
Please investigate execute_bash stdout/receipt routing/session isolation. This appears to be a command-channel integrity bug, not a normal shell error.

### Steps to reproduce

The issue is intermittent, so I cannot reproduce it on every run. I can reproduce/observe it by running a sequence of execute_bash commands that each write a unique marker and receipt file, then immediately asking Kiro to read the corresponding receipt.

Reproduction pattern:

1. In a Kiro chat session, ask the agent to run shell commands one at a time using unique markers, for example:
- command A writes output to /tmp/kiro_canary_A.txt and echoes CANARY_A_MARKER
- command B writes output to /tmp/kiro_canary_B.txt and echoes CANARY_B_MARKER
- command C writes output to /tmp/kiro_canary_C.txt and echoes CANARY_C_MARKER
- command D writes output to /tmp/kiro_canary_D.txt and echoes CANARY_D_MARKER

2. After each command, have the agent read the expected receipt file and compare:
- the stdout marker shown by execute_bash
- the marker written inside the receipt file
- the expected command/receipt pairing

3. Repeat across several commands or sessions.

Expected result:
Each command’s stdout marker and receipt file should match the command just issued.

Actual intermittent result:
The next observed stdout or receipt sometimes contains a marker from a prior command, or the agent observes a receipt/marker that does not correspond to the command it just issued.

Example observed mismatch:
After later commands, Kiro displayed a prior marker such as RECON7B_MARKER/H_MARKER/I_MARKER instead of the marker for the current command. In another session, the canary sequence failed at Canary C, so Kiro correctly stopped before performing git add/git commit.

Important note:
A later fresh session ran canaries A/B/C/D successfully, so the issue is not constant. The problem is intermittent command-channel integrity, not a deterministic shell command failure.

### Environment

```yaml

[q-details]
version = "2.18.1"
hash = "74b78bb5a369788e393b06654b2b213d937a41d2"
date = "2026-08-13T23:20:56.707604Z (3d ago)"
variant = "full"

[system-info]
os = "macOS 12.7.6 (21H1320)"
chip = "Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz"
total-cores = 4
memory = "16.00 GB"

[environment]
cwd = "/Users/USER"
cli-path = "/Users/USER"
os = "Mac"
shell-path = "/bin/zsh"
shell-version = "5.8"
terminal = "macOS"
install-method = "unknown"

[env-vars]
PATH = "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/USER/.local/bin"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.apple.Terminal"
```

Start by locating the execute_bash entry point and the stdout/receipt handling involved in command execution. Reproduce the issue with the documented A-D unique-marker sequence across repeated commands or sessions, then verify that each stdout marker, receipt file, and command result remain paired consistently.

Written by the indexing model from the issue text.