Manage ownership semantics

A subsystem currently shares ownership of large configuration objects by copying them everywhere; this causes memory spikes and update inconsistencies. Rework ownership semantics: make the config immutable and share it by shared ownership, or convert to move-only with unique ownership and explicit hand-offs during reload. Implement one approach and update call sites so ownership rules are explicit and safe for concurrent readers.

Before I change how we own and pass configuration objects, make the change easy to review: summarize the chosen ownership model at the top of the PR, show example call sites before and after, call out concurrency implications for readers during reload, and list migration steps for code that currently copies configs. Highlight performance and thread-safety trade-offs to expect in testing.

On config reload the system either duplicates huge objects or some threads read a partially-updated config. I’m not sure whether to use shared immutable configs or move-only ownership with a hand-off. Diagnose the likely thread-safety and performance trade-offs and recommend the next move: implement immutable shared_ptr-style snapshots for cheap reads, or move to unique ownership with a synchronized swap. Explain one concrete change I can make first to stop races with minimal code churn.

Across services we habitually copy large configuration and state objects, which inflates memory use and causes stale or inconsistent reads during reloads. Where are we losing time and credibility, and what habit should change? Recommend a default ownership policy: prefer immutable, shared snapshots for read-heavy data and move-only updates for writers; require a one-line ownership comment on types larger than 1KB. Provide a short checklist for refactoring hotspots.