Fix field_caps API incorrectly returning object types with types filter

[natea]

Summary

This PR fixes issue #109797 where the _field_caps API incorrectly returns object and nested fields when using the types parameter, even when those types are not included in the filter.

Problem

When requesting specific field types using the types parameter (e.g., types=text), the API was incorrectly including parent object fields if they had child fields matching the requested type. This behavior was inconsistent with the documented API behavior.

Example

// Index mapping
{
  "properties": {
    "product": {
      "type": "object",
      "properties": {
        "name": { "type": "text" },
        "price": { "type": "float" }
      }
    }
  }
}

// Request: GET /index/_field_caps?fields=*&types=text

// Before (incorrect): Returns both product.name AND product
// After (correct): Returns only product.name

Solution

Modified the parent object inclusion logic in FieldCapabilitiesFetcher.java to respect the types filter. Parent object/nested fields are now only included if their type is explicitly requested in the types parameter.

Changes

• FieldCapabilitiesFetcher.java: Added types filter check before including parent object fields (lines 210-215)
• FieldCapabilitiesTypesFilterTests.java: Added comprehensive unit tests covering various scenarios
• 60_types_filter_objects.yml: Added REST API tests to verify correct behavior

Testing

• ✅ All existing field capabilities tests pass
• ✅ Added 5 unit test methods covering different filter combinations
• ✅ Added 6 REST API test scenarios
• ✅ Tests verify object/nested fields are excluded when not in types filter
• ✅ Tests verify object/nested fields are included when explicitly requested

Related Issues

Fixes #109797

Checklist

• I have signed the Contributor License Agreement
• I have run the tests locally and they pass
• I have added tests that prove my fix is effective
• I have added necessary documentation (API behavior is now consistent with docs)
• My changes follow the existing code style

🤖 Generated with Claude Code

Co-Authored-By: Claude [email protected]

[elasticsearchmachine]

Pinging @elastic/es-search-foundations (Team:Search Foundations)