Preserve error status when run events exceed the capture limit

[larissaschiavo]

An HTTP 429 error can contain the full request body. When that pushes a model-response event past the 64 KiB capture limit, the event currently clears error entirely, leaving observers unable to distinguish the provider failure from an oversized successful response.

Retain a truncated-error marker with validated HTTP status, a short identifier-shaped provider code, and boolean retryability when available. These fields are selected after redaction; messages, request/response bodies, headers, causes, and arbitrary nested values are discarded. Tight capture limits reduce the summary to a marker or the existing envelope. Ordinary events, successful-response truncation, returned errors, and execution/retry behavior stay unchanged.

Validation:

• The added 215 KB provider-error and refusal regressions fail on upstream main before the change.
• Final focused run: mix test test/run_observation_test.exs test/run_test.exs --seed 0 — 22 tests pass, including secret exclusion, newline/oversized code rejection, tight limits, and unchanged ordinary/successful events.
• mix check passes on the final commit: formatting, warnings-as-errors compilation, 54 doctests, 9 properties, 2912 tests, zero failures (13 skipped, 261 excluded).
• No live provider requests or external model calls.