Refactor runtime state for atomic configuration updates

[ktrubilo9]

Summary

Refactors runtime state management so requests always use one consistent configuration version during concurrent admin updates.

Changes

• Introduce immutable RuntimeState published through atomic.Pointer
• Load one runtime state for the complete request lifecycle
• Add a concurrency-safe backend status registry
• Preserve backend statuses across compatible configuration updates
• Keep status views available to requests using an older runtime state
• Serialize configuration mutations through applyUpdate
• Atomically publish snapshot, HTTP client, load balancer, and status view
• Reuse the HTTP client when transport settings are unchanged
• Rebuild the HTTP client only when timeout configuration changes
• Rebuild the load balancer only when its strategy changes
• Close idle connections of replaced HTTP clients
• Synchronize backend metrics during configuration updates
• Make rate-limit callbacks concurrency-safe and optional
• Update health checks and operational handlers to use consistent state views

Testing

Added tests covering:

• backend status reconciliation
• preservation and removal of backend statuses
• runtime component reuse
• failed configuration updates
• concurrent configuration mutations
• old state visibility after backend removal
• concurrent proxy traffic during routing updates
• HTTP client preservation during routing changes