HTTP interceptor pipeline for Ring request/response processing.

This namespace provides an HTTP-specific interceptor chain that runs over Ring handlers,
giving Pedestal-like enter/leave/error semantics while maintaining Ring compatibility.

Key Benefits:
- Consistent cross-layer observability (HTTP → service → persistence)
- Declarative per-route policies (auth, rate-limit, auditing)
- Clean separation of concerns (routing vs cross-cutting logic)
- Reusable interceptor components across routes

HTTP Context Model:
{:request       Ring request map
 :response      Ring response map (built up through pipeline)
 :route         Route metadata from Reitit match
 :path-params   Extracted path parameters
 :query-params  Extracted query parameters
 :system        Observability services {:logger :metrics-emitter :error-reporter}
 :attrs         Additional attributes set by interceptors
 :correlation-id Unique request ID
 :started-at    Request start timestamp}

Interceptor Shape:
{:name   :my-interceptor
 :enter  (fn [context] ...) ; Process request, modify context
 :leave  (fn [context] ...) ; Process response, modify context
 :error  (fn [context] ...)} ; Handle exceptions, produce safe response

Usage:
;; As Ring middleware (global)
(def handler
  (-> app-handler
      (wrap-http-interceptors [logging metrics error-reporting])))

;; Per-route via Reitit :middleware
{:get {:handler my-handler
       :middleware [(interceptor-middleware [auth rate-limit])]}}

Integration with Normalized Routes:
- Normalized routes can specify :interceptors vector
- Reitit adapter translates :interceptors → :middleware with this runner

Reitit router adapter - converts normalized route specs to Reitit routing.

This adapter implements the IRouter protocol to translate framework-agnostic
normalized route specifications into Reitit-specific route definitions.

Ring+Jetty server adapter - manages HTTP server lifecycle using Ring and Jetty.

This adapter implements the IHttpServer protocol to start and stop Jetty-based
HTTP servers with Ring handlers.

HTTP API versioning support - wraps routes with version prefixes and headers.

SIDE EFFECTS:
- Route transformation
- Response header modification
- Logging

Provides URL-based versioning (/api/v1/users, /api/v2/users) with:
- Automatic version prefix wrapping
- Version header injection (X-API-Version, X-API-Latest, X-API-Deprecated)
- Backward compatibility (/api/users → /api/v1/users redirect)
- Multiple version support concurrently