fix(opentelemetry source): return 4xx instead of 500 for rejected HTTP requests

[Andrew-Hinson]

Summary

The opentelemetry source's OTLP/HTTP rejection handler returned 500 Internal Server Error
for every warp rejection that wasn't an ErrorMessage, with the rejection's Debug output
(e.g. Rejection(InvalidHeader { name: "content-type" })) as the message. So a client
sending the wrong content type got what looked like a server crash.

This PR maps those rejections to the right client errors:

• unsupported or missing Content-Type is now 415 Unsupported Media Type
• non-POST method now returns 405 Method Not Allowed
• unknown path now returns 404 Not Found

Anything else still returns 500. This is the minimal fix suggested in the issue; accepting
OTLP/HTTP JSON would be a separate feature.

One thing I left out of scope: a malformed content-encoding header still returns 500.

Most of this change was written with Claude Opus 5.5; I reviewed and tested it.

References

Closes: #26456

Vector configuration

sources:
  otlp:
    type: opentelemetry
    grpc:
      address: 127.0.0.1:4317
    http:
      address: 127.0.0.1:4318
sinks:
  console:
    type: console
    inputs: [otlp.logs]
    encoding:
      codec: json

How did you test this PR?

Added http_rejections_return_client_error_status_codes, which fails on master and passes
with this change:

cargo test -p vector --lib --features sources-opentelemetry sources::opentelemetry

All OpenTelemetry source tests pass (Rust 1.96.1, Arch Linux).

I also ran a local build with the config above and sent requests with curl:

Request	Before	After
POST, Content-Type: application/json	500	415
POST, no Content-Type	500	415
GET /v1/logs	500	405
POST /v1/nope	500	404
POST, application/x-protobuf	200	200

Does this PR include user facing changes?

• Yes. created the required changelog:
  changelog.d/26456_opentelemetry_http_rejection_status.fix.md

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[Andrew-Hinson]

I have read the CLA Document and I hereby sign the CLA

[thomasqueirozb]

Could we use some code similar to this to implement the fall-through cases here instead of handling one-by-one?

[Andrew-Hinson]

@thomasqueirozb yes good idea, on it.

[Andrew-Hinson]

@thomasqueirozb Done, the one trade off is that those responses now have plain text bodies instead of protobuf though.