Fix: Support non-JSON content types for request body validation

[roidelapluie]

Previously, Huma was hardcoded to look for the validation schema in RequestBody.Content["application/json"]. This caused validation to fail when operations only specified other content types like application/cbor or application/x-www-form-urlencoded.

This commit makes the schema lookup more flexible:

1. First try application/json for backwards compatibility
2. If not found, fall back to the first available content type with a schema

This allows operations to use contentType tags to specify non-JSON request bodies while still benefiting from Huma's validation.

[richard-hunter-hpe]

@roidelapluie will this address #833? I've been trying to use application/merge-patch+json Content Type on an input body, and while it works in the spec generation, get runtime errors during input validation due to a nil schema reference. With this change things seem to work. It would be great to get this bug fixed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.95%. Comparing base (20f5e04) to head (8761e85).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #926      +/-   ##
==========================================
+ Coverage   92.90%   92.95%   +0.05%     
==========================================
  Files          23       23              
  Lines        4621     4628       +7     
==========================================
+ Hits         4293     4302       +9     
+ Misses        271      270       -1     
+ Partials       57       56       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[wolveix]

Hey @roidelapluie! This is an awesome change, thanks so much for contributing!

[wolveix]

@richard-hunter-hpe no, this doesn't resolve that issue. But I have a fix locally for it, and will push it shortly :)