Clarify OpenAPI traffic matching

[nizox]

What does this PR do? What is the motivation?

Clarifies how Datadog combines endpoints declared in OpenAPI specifications with endpoints discovered from traffic, so users can understand why entries merge, remain separate, or match too broadly.

Changes

• Documents matching by implementing service, HTTP method, and path.
• Identifies the exact span attributes used for method and path matching: http.method, http.url_details.path, and http.route.
• Explains base_service and normalized http.route fallbacks.
• Adds separate troubleshooting entries for definition/traffic mismatches and catch-all definitions, with examples.
• Preserves the existing troubleshooting entry for definitions that match too many services.
• Clarifies the behavior of definition-only endpoints.

Merge readiness

• Ready for merge

For Datadog employees:

• ⚠️ Your branch name MUST follow the <name>/<description> convention and include the forward slash (/). If you've already created your PR with an incorrect branch name, please rename your branch and open a fresh PR.
• 🤖 New: Comment with /review to run an automated check that catches common issues before a Documentation team member reviews your PR.

AI assistance

Used Bits Code to inspect the actual implementation, draft the documentation changes, and run validation.

Additional notes

The matching behavior was verified against the production service implementation.

[github-actions]

⚠️ Possible site support note detected

The following files have a site-region shortcode at the top of the page that mentions a feature being "not available" or "not supported":

• content/en/internal_developer_portal/catalog/endpoints/_index.md

Are you trying to document site support for a product? If so, the site-region shortcode is not the recommended approach. See the Documenting site support guide for the preferred method.

[github-actions]

Preview links (active after the build_preview check completes)

Modified Files

• https://docs-staging.datadoghq.com/nicolas.vivet/openapi-traffic-matching/internal_developer_portal/catalog/endpoints/
• https://docs-staging.datadoghq.com/nicolas.vivet/openapi-traffic-matching/internal_developer_portal/catalog/troubleshooting

[drichards-87]

@nizox Approving the PR but wanted to note that the other H3s under Getting started are all tasks ("Exploring endpoints," "Monitoring endpoints," "Assigning owners," etc.), each with a short blurb and a "Read more" link. "How OpenAPI specifications are combined with traffic" is conceptual/explanatory rather than a task, so it feels out of place in this section. Could this move somewhere more fitting, for example, a "How it works" section or the relevant sub-page? Leaving placement to you since you know the product area best.