[JoshuaFrenchwood]

What was changed

Nexus operation handlers now propagate their NexusSerializationContext to the workflow updates they send.

• Handler: update requests sent inside a Nexus operation handler, including update-with-start, carry the context.
• Worker: the update's result, failure and validator rejection are encoded with the context from DoUpdate, at both the converter and codec layers. Updates have no sequence number, so the codec looks up the context by protocol instance ID. The context is kept until the activation that finished the update has been encoded. Replay gets the same context, since Core builds DoUpdate from history.
• Update arguments keep the workflow context.
• Clients: WorkflowUpdateHandle.result() decodes with the context returned on the update and poll responses, so a handle obtained with get_update_handle decodes correctly.

Why?

A Nexus handler returns the result and failure of the update it sends to the Nexus caller. The caller decodes them with the operation's NexusSerializationContext, so a codec keyed on the context couldn't decode them when they were encoded with the workflow context.

Checklist

1. Closes

2. How was this tested:

• test_nexus_sent_update_uses_nexus_context[result|failure|rejection] runs on the dev server with the strict Nexus marker codec. It checks:
  • The Nexus caller gets the result or failure.
  • An update handle obtained by ID decodes the result or failure with the server's context.
  • In history, the accepted request carries the context, the update input is unmarked, and the completed outcome is marked.
  • Rejections aren't stored in history, so a client interceptor checks that the rejection the handler receives is marked.
  • Replaying the history with Replayer succeeds.

3. Any docs updates needed?