Fix exact-cap app-server capReached reporting

[etraut-openai]

Addresses #22379

Why

capReached is meant to signal that outputBytesCap actually truncated a stream. The app-server output collectors instead treated "captured byte count equals the cap" as truncation, so output that landed exactly on the cap boundary could be reported as clipped even when no bytes were dropped.

What changed

• Derive capReached from whether the emitted chunk was shortened in both command/exec and process/spawn.
• Add exact-cap coverage for streamed command/exec output.
• Retarget the buffered process/spawn cap regression to cover the exact-boundary case from the issue.

Verification

• cargo test -p codex-app-server cap_reached

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 61a586599c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Update process capReached docs for exact-cap outputs

This changes process/spawn to report stdoutCapReached/stderrCapReached as false when a stream's output length exactly equals outputBytesCap, but the public process API docs/schema still describe these fields as reporting whether the stream “reached” the cap (for example app-server/README.md:1090 and the protocol comments that generate the schema). In the exact-cap case, clients following those docs would expect true while the server now sends false; the app-server API guidance in AGENTS.md also requires updating docs/examples when API behavior changes.

Useful? React with 👍 / 👎.