Feature: Istio-style header-based routing

## Summary

Add support for routing requests to different upstream backends based on **HTTP request headers**, similar to [Istio VirtualService HTTPMatchRequest](https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPMatchRequest) patterns (match on specific header names/values, optional prefixes, regex, etc.).

## Motivation

- Common need for canary releases, A/B tests, tenant isolation, and API versioning via headers (e.g. `X-Canary: true`, `X-Tenant-Id`, `Accept-Version`).
- Aligns with how service meshes and ingress controllers express traffic splitting without path-only rules.

## Possible scope (discussion)

- Match rules: exact header value, prefix, presence (header exists), perhaps case normalization for header names.
- Precedence: order of rules, default/fallback route when no header matches.
- Interaction with existing host/path routing; document semantics when multiple rules could match.

## Acceptance criteria (draft)

- [ ] Configurable header match conditions associated with a route or upstream.
- [ ] Clear precedence and fallback behavior documented.
- [ ] Tests covering typical Istio-like match cases.

---

*Feel free to adjust scope based on project goals and config format.*

Start by reading the existing host/path routing implementation and configuration format, then compare the proposed exact, prefix, presence, and regex header matches with the project's current semantics. Define rule precedence, fallback behavior, and interaction with host/path routing before adding tests for the agreed Istio-like cases.

Written by the indexing model from the issue text.