Add NexusOperationHandler annotation

[Quinn-With-Two-Ns]

What was changed

Add NexusOperationHandler annotation that can be used in Nexus Service Handlers on Temporal Workers

Why?

Makes it easier to declare Nexus Service Handlers with less boilerplate

Checklist

1. Closes

2. How was this tested:

3. Any docs updates needed?

Note to reviewers:
nexus-rpc/sdk-dotnet#19 needs to land first and most of the package lock changes are only here to test locally

---

Note

Medium Risk
Touches experimental Nexus operation registration, reflection/expression binding, and hosting DI scoping; build currently depends on a local NexusRpc project reference until the companion SDK change ships.

Overview
Adds [TemporalOperation] so a method on a [NexusServiceHandler] class can be the Nexus operation start handler directly (signature Task<TemporalOperationResult<T>> with TemporalOperationStartContext and ITemporalNexusClient), instead of returning an IOperationHandler from a [NexusOperationHandler] factory. Registration wires this through a new TemporalOperationMethodExtension (IMethodExtension) that validates signatures and builds TemporalOperationHandler via compiled delegates; AddNexusService on workers and simple plugins now passes that extension into ServiceHandlerInstance.FromInstance.

Hosting is refactored so ServiceHandlerInstanceHelper discovers operations by method name and delegates to a factory that supports both attribute styles. [TemporalOperation] handlers get per start/cancel DI scopes (like activities), reusing the same validation/factory internals via InternalsVisibleTo. Unmatched [NexusOperationHandler] methods fail registration consistently with NexusRpc.

Temporalio temporarily references the local NexusRpc project (instead of the NuGet package) to pick up extension APIs pending the upstream Nexus SDK PR; lockfiles reflect that. Changelog and broad integration tests cover workflow starts, sync results, void/no-input ops, mixed handlers on one service, and registration errors.

^{Reviewed by Cursor Bugbot for commit 24200f6. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f76d3e21a7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[jmaeagle99]

Small amount of feedback, but looks good overall. Will approve when dependency has been updated.

Side note: this is ripe for source generation, which would create compile-time safe operation registration, but still use the reflection and expression compilation as a fallback. I'm going to log an issue to track this, as there are other areas that can benefit as well.

[jmaeagle99]

Please update CHANGELOG.md with a blurb in the Added section.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 1f2f3e3. Configure here.}

[jmaeagle99]

I think the one pitfall of this design is that if a method is attributed with [TemporalOperation] but it's name doesn't match a method in the service interface, then it is silently ignored. This might lead to typo-created mismatches given that the service implementation doesn't implemented the service interface. Not sure what to do with that without given the entire service definition to Temporalio to validate all attributed methods at once. Maybe could be done better with an analyzer.