Python: resolve postponed @response_handler annotations - #8328

Motivation & Context

The introspection path of @response_handler reads raw values from inspect.signature(func). With from __future__ import annotations, valid request, response, and WorkflowContext[...] annotations are strings, so a valid executor class currently fails during decoration with ValueError and cannot be imported or instantiated. The existing @handler path already resolves these annotations; issue #8327 tracks the missing response-handler counterpart.

The bug was reproduced on clean upstream commit 3c670707766a8455da6491a9049cc9d575e019f0 with a four-parameter response handler using original_request: str, response: int, and ctx: WorkflowContext[str].

Description & Review Guide

• What are the major changes?
  • Resolve response-handler annotations with typing.get_type_hints(func) during signature validation, matching the existing @handler behavior.
  • Fall back to raw annotations when resolution fails, preserving the existing diagnostic path for unresolved references.
  • Add a future-annotation regression test that verifies request type, response type, and workflow output type registration.
• What is the impact of these changes?
  • Executors using postponed annotations can define and register @response_handler methods normally.
  • Existing handlers with evaluated annotations and explicit decorator type parameters retain their behavior.
  • Before the fix, the executor definition raised ValueError: Response handler parameter 'ctx' must be annotated ... got WorkflowContext[str]; after the fix it registers (str, int) with workflow output type str.
  • Verification evidence: the full core suite passed with 5044 passed, 131 skipped, 2 xfailed; relevant request-info, executor, and future-annotation tests passed; Ruff format/lint passed; Pyright reported 0 errors, 0 warnings for both changed files.
• What do you want reviewers to focus on?
  • Whether the response-handler resolution and fallback behavior correctly mirror _validate_handler_signature.
  • Whether the regression test covers the public decorator/discovery path without changing explicit-parameter behavior.

Related Issue

Fixes #8327

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.