Use strict Base64 decoding for result_chunk to match strict encoding

[nficano]

Category: bug Severity: minor
Location: lib/arcp/job/event_body/result_chunk.rb:33-38 (secondary: lib/arcp/runtime/job_context.rb:155)
Spec: ARCP v1.1 §8.4

What

ChunkWriter#write encodes binary chunks with Base64.strict_encode64, but ResultChunk#decoded decodes with the lenient Base64.decode64, which ignores non-alphabet characters and stops silently at malformed input. The encode/decode pair is asymmetric: a corrupted or truncated data field (e.g. line-wrapped or whitespace-injected by an intermediary) is silently mis-decoded into wrong bytes instead of being rejected, so chunked-result assembly (§8.4) can yield a corrupt result with no error. For binary payloads this is a silent data-integrity hazard.

Evidence

# lib/arcp/job/event_body/result_chunk.rb:33-38
def decoded
  case encoding
  when 'utf8'   then data
  when 'base64' then Base64.decode64(data)   # lenient; encoder uses strict_encode64
  end
end

# lib/arcp/runtime/job_context.rb:155
when 'base64' then Base64.strict_encode64(chunk)

Proposed fix

Decode with Base64.strict_decode64(data) so malformed input raises rather than silently truncating, mirroring the strict encoder; convert the resulting ArgumentError into Arcp::Errors::InvalidRequest for a clean wire error. Add a round-trip test for binary data and a negative test asserting that malformed base64 raises.

Acceptance criteria

• decoded uses strict base64 decoding for encoding == 'base64'.
• Malformed base64 surfaces an InvalidRequest rather than corrupt bytes.
• Binary round-trip (encode → decode) is byte-exact.