feat: Add prompt parameter support for stored prompts in Responses API (Fixes #500)

[YairSadan]

Summary

This PR implements support for stored prompts in the OpenAI .NET SDK Responses API, addressing the feature request in issue #500. The implementation brings the .NET SDK to feature parity with the JavaScript SDK for stored prompt functionality.

Changes

Core Implementation

• ResponsePrompt.cs: New class representing stored prompts with Id, Version, and Variables properties
• ResponsePrompt.Serialization.cs: Complete JSON serialization support with trimming compatibility (IL2026 compliant)
• ResponseCreationOptions.cs: Added Prompt property to enable stored prompt usage

Testing & Examples

• Unit Tests: Added comprehensive serialization/deserialization tests in ResponsesTests.cs
• Sync Example: Example03_StoredPrompts.cs demonstrating synchronous usage
• Async Example: Example03_StoredPromptsAsync.cs demonstrating asynchronous usage

Features

✅ Stored Prompt Support: Full implementation matching JavaScript SDK functionality
✅ Variable Substitution: Support for prompt variables with type-safe handling
✅ JSON Serialization: Custom IJsonModel implementation with proper error handling
✅ Trimming Compatibility: All IL2026 warnings resolved for AOT scenarios
✅ Pattern Compliance: Follows existing codebase conventions and patterns
✅ Comprehensive Testing: Unit tests covering serialization, deserialization, and integration

Usage Example

var options = new ResponseCreationOptions
{
    Prompt = new ResponsePrompt
    {
        Id = "pmpt_abc123",
        Version = "v1.0"
    }
};

// Add variables for prompt substitution
options.Prompt.Variables["customer_name"] = "Jane Doe";
options.Prompt.Variables["product"] = "40oz juice box";

// Use with responses client
OpenAIResponse response = await client.CreateResponseAsync(inputItems, options);

API Compatibility

This implementation enables the same functionality as the JavaScript SDK:

JavaScript:

const response = await client.responses.create({
    model: "gpt-4o",
    prompt: {
        id: "pmpt_abc123",
        version: "2",
        variables: {
            customer_name: "Jane Doe",
            product: "40oz juice box"
        }
    }
});

C# (with this PR):

var response = await client.CreateResponseAsync(inputItems, new ResponseCreationOptions
{
    Prompt = new ResponsePrompt
    {
        Id = "pmpt_abc123",
        Version = "2",
        Variables = {
            ["customer_name"] = "Jane Doe",
            ["product"] = "40oz juice box"
        }
    }
});

Technical Details

• Serialization: Custom IJsonModel<ResponsePrompt> implementation handles all primitive types and complex objects
• Performance: Uses WriteRawValue for .NET 6.0+ with fallback for earlier versions
• Type Safety: Variables stored as IDictionary<string, object> with proper JSON deserialization
• Integration: Seamlessly integrates with existing ResponseCreationOptions workflow

Testing

All tests pass and the project builds successfully in Release configuration:

Build succeeded.
    0 Warning(s)
    0 Error(s)

Breaking Changes

None. This is a purely additive feature that maintains full backward compatibility.

Fixes #500

[jsquire]

Hi @YairSadan. Thanks very much for your contribution and your interest in improving the OpenAI developer experience. First, I'd like to tell you how much we appreciate your rigor and attention to detail - you've managed to mimic the existing conventions and approach perfectly.

This one is a bit tricky, in that the implementation is for a feature that is in a newer version of the REST API spec than our upstream repository currently references. While you've done a great job ensuring that your implementation only touches custom code (so that it isn't impacted by automatic generation), it is overlapping an area that will be generated and makes some assumptions about the naming and structure of the spec. The assumptions are well-reasoned and based on the API docs and JS implantation - so probably safe.

When we do generate the feature, either we'll see your implementation integrate perfectly or cause generation/build failures. It's hard to predict until we receive a spec hand-off. I'm inclined to say that the quality of your work offsets a great deal of that risk and that we should accept the changes - but @joseharriaga is the expert on what is happening upstream, so I'm going to ask that he makes the call.

Regardless of how things work out, your efforts and professionalism are very much appreciated.