feat(ocsf): carry structured events on sandbox log stream

[krishicks]

Summary

Carry each sandbox OCSF event as JSON alongside the log line so the gateway and downstream exporters retain the complete event instead of reparsing shorthand text.

Render display text from the decoded event at the gateway. Preserve the original message when a line has no structured payload or the payload cannot be decoded.

Related Issue

#1055

Changes

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[johntmyers]

Review findings

• [P1] Preserve the fallback message for mixed-version gateways. For OCSF events, LogPushLayer now sets message to an empty string and carries the content only in the new ocsf_json protobuf field (log_push.rs:54-91). A pre-feat(ocsf): carry structured events on sandbox log stream #3104 gateway ignores unknown field 8 and publishes the empty fallback, so OCSF entries appear blank when a newer supervisor reconnects to an older gateway during a rollout or rollback. Supervisor images can be pinned independently, so this mixed-version pairing is supported and realistic. Please keep message populated with the shorthand representation and treat ocsf_json as additive metadata, or negotiate support before clearing the fallback.

• [P2] Expose the structured payload through the curated Go SDK. The protobuf gains ocsf_json, but types.LogLine has no corresponding field (types/log.go:9-21) and LogLineFromProto does not copy GetOcsfJson() (converter/log.go:18-25). Exporters using the curated API therefore still cannot retain the complete event. Please add a deep-copied byte field or parsed OCSF representation and converter coverage.

[krishicks]

@johntmyers

Supervisor images can be pinned independently, so this mixed-version pairing is supported and realistic.

Is this really the case? I know previously the supervisor was always using the latest image, but do we make any guarantees about using a newer supervisor with an older gateway?

[krishicks]

@johntmyers

Expose the structured payload through the curated Go SDK.

I think this should be done as a separate PR. Thoughts?

[johntmyers]

@johntmyers

Supervisor images can be pinned independently, so this mixed-version pairing is supported and realistic.

Is this really the case? I know previously the supervisor was always using the latest image, but do we make any guarantees about using a newer supervisor with an older gateway?

I don't think we explicitly prevent this case. Maybe for pre-0.1.0 this doesn't matter. But I think the review agent was orienting around HA rolling upgrades where the mismatch could happen.