feature: send an X-Priority header, per-request with a client-wide default

[dgarros]

Component

Python SDK

Describe the Feature Request

The SDK should be able to attach an X-Priority header to the requests it
sends to Infrahub, so the server can classify traffic for priority-aware
backpressure and shed less-important requests first.

The header carries one of three values — high, normal, or low — where
normal is the implicit default when nothing is sent (opting up to high
or down to low is the only reason to set it explicitly).

Two ways of setting it are needed:

• Per-request override — a caller can set the priority for a single
  request, so the code path that originates the request (which knows why
  it's being made) can tag it honestly.
• Client-wide default — a client instance can be configured with a
  default priority that applies to every request it issues, unless overridden
  per request. This guarantees that once a default is configured, every use of
  that client honours it (e.g. a client dedicated to background work sends
  low on everything).

Both the async (InfrahubClient) and sync (InfrahubClientSync) clients
should share this behaviour.

Describe the Use Case

Clients (including infrahubctl and the Infrahub Ansible collection, which
use this SDK internally) mix user-blocking work with deferrable background
work — batches, syncs, generators, prefetches. Without a way to signal
importance, the server can only shed load blindly and hurt everyone equally.
Letting callers tag requests — reserving high for work a user is actively
waiting on and pushing background/best-effort traffic to low — lets the
server protect what matters and shed the right thing first. A configurable
client-wide default means whole classes of traffic (e.g. all background jobs)
can be tagged in one place rather than at every call site.

Additional Information

This is the client-side complement to #1124 (retry/backoff on HTTP 429). That
issue owns 429 handling; this one is scoped to sending the priority header
and configuring it.

Suggested notes (non-binding):

• A single request-priority concept (e.g. Priority.HIGH/NORMAL/LOW) that the
  HTTP layer maps to the X-Priority header, so call sites express intent
  rather than header strings.
• The client-wide default fits naturally in the existing pydantic Config.
• Server contract: values are case-insensitive; an unknown or absent value is
  treated as normal, so rollout is safe and can be adopted incrementally.
• Priority should reflect what a request is, not be escalated to dodge
  shedding.

Related: #1124