fix: mark system Nexus envelope payloads

[tconley1428]

What changed

• Mark System Nexus envelopes when they are created.
• Detect marked envelopes anywhere workflow codecs visit a payload, so nested user payloads are encoded and decoded after an envelope is stored in a generic payload field.
• Keep unmarked payloads on the regular codec path and preserve batch codec behavior for ordinary payload collections.

Blocked on server behavior

This stacked draft depends on #846. It must not be completed until the server marks System Nexus
operation result payloads as System envelopes too. The server currently returns an unmarked
binary-protobuf completion payload, which a workflow codec correctly treats as an ordinary payload
and may transform, making the outer response no longer parseable.

[jmaeagle99]

This payload possibly does not have the system payload marker on it even if it is a system payload. Which means that it'll go through the normal user codec decode path and then fail deserialization causing the workflow to continuously fail the task and timeout the ExecuteWorkflowAsync_SignalWithStartFromWorkflow_Succeeds test. Might need to check for the marker or see if it's from the system nexus endpoint; or maybe somehow stamp the payload with the marker if it comes from the system nexus endpoint before we attempt the decode here.

[tconley1428]

In what scenario would it be a system payload without the system payload marker? That should be tautologically equivalent as far as I know. (At least once server is updated sufficiently) Are you talking backwards compat or something else?

[jmaeagle99]

Back compat. Today, system payloads are identified by the endpoint, but this change completely drops that (I think). So in-flight workflows that do not have the new marker now going through the path of decoding the envelop. But if you don't care about those, then I think this is fine.

But I see that ExecuteWorkflowAsync_SignalWithStartFromWorkflow_Succeeds hung in every job. It's likely retrying a workflow task indefinitely for some reason. Probably due to the missing marker.

[tconley1428]

Yeah, this was in draft for a reason. All you say is true, but it's also not enabled at all yet, so we're good to do the breaking change. Nice catch though.