feat: Allow API callers to inject a request-id header

[Dhanus3133]

Why

The API generates a request_id for each incoming request and carries it through the message bus into the task workers, so one request can be traced across systems. But the caller can't supply their own id, so an external system (the git-agent over the SDK, or any API user) has no way to tie that activity back to its own side.

Closes #559

What changed

• The API now accepts an optional X-Infrahub-Request-Id header, logs it as user_request_id (separate from the generated request_id), and propagates it through the message bus to worker logs. Backward compatible, empty default.

How to test

uv run pytest backend/tests/unit/message_bus/test_meta.py

Checklist

• Tests added/updated
• Changelog entry added (uv run towncrier create ...)
• External docs updated (if user-facing or ops-facing change)
• Internal .md docs updated (internal knowledge and AI code tools knowledge)
• I have reviewed AI generated content

---

Summary by cubic

Let API callers pass a request ID via the X-Infrahub-Request-Id header. We log it as user_request_id and propagate it across the message bus, RPC paths, and git workers for end-to-end traceability.

• New Features
  • API middleware reads optional X-Infrahub-Request-Id and stores it as user_request_id in the log context.
  • Added user_request_id to Meta; propagated via assign_meta, set_log_data, _add_request_id enrichers, and both nats/rabbitmq adapters (including RPC).
  • Git tasks include user_request_id in all emitted messages.
  • Unit tests cover propagation, log binding, and adapter enrichment. Backward compatible when the header is absent.

^{Written for commit 30b0f49. Summary will update on new commits.}