/compact fails with a hard 60s timeout on longer sessions

### 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 26.5.1 (25F80)

### Expected behaviour

## Summary

`/compact` consistently fails on longer sessions. The failure is a hard
60-second client-side timeout, not an upstream API error.

## Evidence

From `~/.kiro/logs/*/kiro.log`. Every failure is exactly 60.0s after
`compaction.start`, matching to the millisecond:

| start (UTC) | messages | result | duration |
|----------------|---------:|--------|---------:|
| 08-02 04:59:29 | 96 | done | 48.4s |
| 08-02 15:19:27 | 251 | failed | 60.0s |
| 08-02 16:01:39 | 251 | failed | 60.0s |
| 08-03 07:07:12 | 291 | failed | 60.0s |

The only successful run (96 messages) already took 48.4s, close to the
ceiling. Millisecond-identical intervals point to a local timer aborting
rather than an upstream failure.

Logged as:

{"timestamp":"2026-08-03T07:07:12.325Z","level":"info","message":"[KiroAgent] compaction.start {\"sessionId\":\"sess_33008086-6223-492e-9600-d3207fca5f19\",\"messages\":291,\"modelId\":\"claude-opus-5\"}"}
{"timestamp":"2026-08-03T07:08:12.325Z","level":"error","message":"[KiroAgent] Compaction failed for session sess_33008086-6223-492e-9600-d3207fca5f19: {}"}

Affected session IDs:

- `sess_33008086-6223-492e-9600-d3207fca5f19` (291 messages, failed)
- `sess_0647ab60-893f-46c6-ab52-be1996882839` (251 messages, failed twice)
- `sess_e97ac523-6c76-4667-8ba0-f3dfbe71346e` (96 messages, succeeded in 48.4s)

## Problems

1. The 60s budget does not scale with message count, so longer sessions can
never compact — which is precisely when compaction is most needed.
2. The error serializes to an empty `{}`, so neither the log nor the CLI
tells the user it was a timeout. Repeated `/compact` attempts look like
silent no-ops.
3. No setting can raise the limit; `kiro-cli settings all` exposes no
compaction or timeout key.

## Expected

Either scale the timeout with message count (or compact in chunks), or
surface a clear message such as "compaction timed out after 60s, consider
starting a new session" with the elapsed time.

## Related issues (searched — not duplicates)

- **#3853** reports auto-compaction *hanging* under `--v3`: unresponsive to
Ctrl+C, process must be killed. This is a different failure mode —
compaction here aborts cleanly at exactly 60s and the CLI stays usable.
That report also bundles four unrelated problems and includes no log
evidence, so the two may still share a root cause worth cross-checking.
- **#2264** surfaces an explicit `The conversation history is too large to
compact` from the Rust path `crates/chat-cli/src/cli/chat/mod.rs:728`
(q 1.12.3). Different code path; this failure originates in `KiroAgent`
and serializes to `{}`.
- **#1323** is an upstream `ValidationException: Input is too long`. This
one is a local timer, not an API rejection — the millisecond-identical
60.0s intervals rule out an upstream cause.

## Environment

kiro-cli 2.16.0, macOS 26.5.1 (arm64), model claude-opus-5

### Actual behaviour

`/compact` appears to do nothing. No error is shown in the CLI, the prompt
simply returns. Running it repeatedly gives the same result, so it looks like
a silent no-op.

The log shows it is being aborted by a hard 60-second timeout. Every failure
is exactly 60.0s after `compaction.start`, matching to the millisecond:

| start (UTC) | messages | result | duration |
|----------------|---------:|--------|---------:|
| 08-02 04:59:29 | 96 | done | 48.4s |
| 08-02 15:19:27 | 251 | failed | 60.0s |
| 08-02 16:01:39 | 251 | failed | 60.0s |
| 08-03 07:07:12 | 291 | failed | 60.0s |

Millisecond-identical intervals point to a local timer aborting rather than
an upstream failure. From `~/.kiro/logs/*/kiro.log`:

```
{"timestamp":"2026-08-03T07:07:12.325Z","level":"info","message":"[KiroAgent] compaction.start {\"sessionId\":\"sess_33008086-6223-492e-9600-d3207fca5f19\",\"messages\":291,\"modelId\":\"claude-opus-5\"}"}
{"timestamp":"2026-08-03T07:08:12.325Z","level":"error","message":"[KiroAgent] Compaction failed for session sess_33008086-6223-492e-9600-d3207fca5f19: {}"}
```

Three things make this hard to live with:

1. The 60s budget does not scale with message count. The only successful run
(96 messages) already took 48.4s, so anything substantially longer cannot
finish — which is precisely when compaction is needed most.
2. The error serializes to an empty `{}`, so neither the log nor the CLI
indicates a timeout. There is no way for a user to tell what went wrong.
3. No setting can raise the limit; `kiro-cli settings all` exposes no
compaction or timeout key.

Affected sessions:

- `sess_33008086-6223-492e-9600-d3207fca5f19` — 291 messages, failed
- `sess_0647ab60-893f-46c6-ab52-be1996882839` — 251 messages, failed twice
- `sess_e97ac523-6c76-4667-8ba0-f3dfbe71346e` — 96 messages, succeeded (48.4s)

Related issues (searched — these are not duplicates):

- #3853 reports auto-compaction *hanging* under `--v3`: unresponsive to
Ctrl+C, process must be killed. Different failure mode — here compaction
aborts cleanly at 60s and the CLI stays usable. That report also bundles
four unrelated problems and has no log evidence, though the two may share
a root cause worth cross-checking.
- #2264 surfaces an explicit `The conversation history is too large to
compact` from the Rust path `crates/chat-cli/src/cli/chat/mod.rs:728`
(q 1.12.3). Different code path; this failure originates in `KiroAgent`.
- #1323 is an upstream `ValidationException: Input is too long`. This one is
a local timer, not an API rejection.

### Steps to reproduce

1. Start a chat session and work until the conversation reaches roughly 250+ messages. Heavy tool use gets there quickly (large API responses, log analysis, repeated file edits). 2. Run /compact. The prompt returns with no visible error and the context is unchanged. 3. Inspect ~/.kiro/logs//kiro.log: a compaction.start entry is followed by Compaction failed ... {} exactly 60.0s later.

For contrast, compaction succeeds on the same machine at ~96 messages, taking 48.4s — so the boundary is the fixed time budget, not a message-count cap.

Note on reproducing faster: what matters is the volume of content compaction has to read, not the message count alone. A session with a few very large tool results (full API responses, log dumps, large file reads) will exceed the budget at a lower message count than a session of short exchanges. In the failing sessions above, much of the bulk came from large tool outputs rather than from conversation turns.

### Environment

```yaml

[q-details]
version = "2.16.0"
hash = "ac4bc3b1417d7cec0c95266cd23b5e7feb8aa3f6"
date = "2026-07-30T22:38:17.601521Z (3d ago)"
variant = "full"

[system-info]
os = "macOS 26.5.1 (25F80)"
chip = "Apple M3"
total-cores = 8
memory = "16.00 GB"

[environment]
cwd = "/private/tmp"
cli-path = "/private/tmp"
os = "Mac"
shell-path = "/opt/homebrew/Cellar/coreutils/9.11/bin/gtimeout"
terminal = "iTerm 2"
install-method = "unknown"

[env-vars]
PATH = "/Users/USER/.pyenv/shims:/Users/USER/.nvm/versions/node/v18.20.6/bin:/Users/USER/.local/bin:/opt/homebrew/opt/mysql@8.0/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/System/Cryptexes/App/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/usr/local/MacGPG2/bin:/opt/homebrew/opt/fzf/bin"
QTERM_SESSION_ID = "c1eb03679d9444559887c199f7bd7eaf"
Q_SET_PARENT_CHECK = "1"
Q_TERM = "2.15.2"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.googlecode.iterm2"
```

Start by tracing the KiroAgent compaction.start path and compare it with crates/chat-cli/src/cli/chat/mod.rs:728, which the issue identifies as a separate Rust path. Reproduce with a session of roughly 250+ messages and inspect ~/.kiro/logs/*/kiro.log. Done means longer compactions no longer fail at a fixed 60 seconds, or the CLI clearly reports the timeout and elapsed time.

Written by the indexing model from the issue text.