[codex] add input field render facet with jinja templates

[darinkishore]

Summary

This PR adds first-class input-field rendering facets for typed signatures, including custom Jinja templates, while preserving the existing #[format("json"|"yaml"|"toon")] path.

Problem

Input rendering previously relied on a stringly FieldSpec.format and only supported a fixed format list. There was no explicit way to define per-input Jinja rendering templates from the signature macro.

That made custom prompt shaping hard, and it also made validation/error reporting less precise for invalid render declarations.

Root Cause

The signature metadata and derive macro only modeled input formatting as Option<&'static str>, and the typed chat renderer only consumed that format string.

There was no first-class render spec enum, no macro grammar for Jinja templates, and no compile-time Jinja syntax validation.

What Changed

1. Added InputRenderSpec to signature metadata with Default, Format(&'static str), and Jinja(&'static str).
2. Extended #[derive(Signature)] with #[render(jinja = "...")] for #[input] fields.
3. Added compile-time Jinja syntax validation in macro expansion.
4. Centralized typed input rendering in ChatAdapter and added strict-undefined Jinja runtime context:
   • this
   • input
   • field (name, rust_name, type)
   • vars
5. Preserved backward compatibility for existing #[format(...)] input behavior.
6. Added duplicate post-alias field-name validation to reject ambiguous input/output field names at compile time.
7. Updated metadata projection to expose Jinja render metadata in typed->legacy conversion paths.

Behavior Notes

• Default non-string typed rendering continues to use OutputFormatContent-aware JSON rendering.
• Jinja input context includes both rust names and alias names at top level for input fields.

Validation

Ran:

• cargo fmt --all
• cargo test -p dsrs_macros
• cargo test -p dspy-rs --test test_input_format
• cargo test -p dspy-rs --test test_adapters

Also ran adversarial review passes and fixed the findings before opening this PR.

[darinkishore]

todo: this is no longer the right solution lmao