fix: large tool inputs break bash PTC replay and pending-call serialization

[kenzaelk98]

Bash PTC tools are meant to handle arbitrary-size input, but the preamble's
internal plumbing quietly assumes inputs stay well under the kernel's
ARG_MAX (~128KB) — which isn't a safe assumption for every PTC use case.

Problem

Three spots in the bash PTC preamble pass raw tool input to jq via
--argjson (a command-line argument), capped by ARG_MAX:

• _ptc_call_tool's pending-call write hits this hard: jq fails outright
  and the script aborts with "Argument list too long."
• _ptc_history_matches_by_signature / _ptc_history_entry_matches_current_call
  hit it silently instead — the error is swallowed, so a cached result never
  matches, and the call re-executes on every replay round rather than
  reusing it.

Fix

Read the input via stdin (pending-call write — stdin is free there) or
--slurpfile (the two matchers — stdin is already used for their primary
input) instead of argv, in all three spots.

Also makes tool_history's per-entry/aggregate byte caps in
replay-state.ts configurable via PTC_MAX_TOOL_RESULT_BYTES /
PTC_MAX_TOOL_HISTORY_TOTAL_BYTES (defaults unchanged), for deployments
whose tools return larger outputs.

Testing

• New bash smoke test: oversized input replays from history on the second
  run instead of re-issuing.
• bun run build / bun run test pass in service/.
• Existing bash smoke suite (93 cases) + the new case all pass.

[CLAassistant]

All committers have signed the CLA.