logger: apply a log config file to the live logger without a restart - #1791

...start
The pieces for changing levels at runtime were already here — the root level and
every component level are zap.AtomicLevel, Config.Update pushes new values into
them, and newSharedConfig registers itself as an update observer — but nothing
ever called Update, so a level change meant restarting the process.
Add the missing trigger: when LK_LOG_CONFIG_PATH is set, poll that file and apply
it to the Config the service is holding (LK_LOG_CONFIG_INTERVAL overrides the
30s default). The hook sits in newSharedConfig, which is the one path every
consumer reaches — livekit-server via InitFromConfig, livekit-sip via
NewZapLogger — so no binary needs its own flag or call site.
Polling rather than fsnotify because the target is a mounted ConfigMap: kubelet
swaps the ..data symlink instead of rewriting the file, so a watch on the file
never fires.
The file is a declarative overlay on the startup config, not on whatever was
applied last: WatchConfigFile snapshots the config once at startup and every file
is decoded over that baseline, so a key the file omits falls back to its startup
value and emptying the file to `{}` restores the levels the process booted with.
Decoding over the config in force instead would make an empty file a no-op once
`level: debug` had been applied, and would keep applying a component_levels entry
after it disappeared from the file.
Two details that would otherwise bite:
- Update assigns every field, so a partial file decoded into a zero Config would
 silently reset the rest. Config.snapshot copies the data fields and the file is
 unmarshalled over that, leaving unspecified keys — including ComponentLevels,
 where livekit-server puts pion_level — as they were.
- sharedConfig kept the caller's live *Config and read ComponentLevels from it
 under its own mutex, while Update writes those fields under Config.lock. Two
 mutexes over the same memory was harmless while Update was unreachable; now it
 is reachable, so sharedConfig holds a snapshot it owns instead.
An unreadable file (an optional ConfigMap not yet mounted), unchanged bytes and
malformed YAML all leave the config in force untouched, without logging once per
interval. A file that goes away is deliberately not a reset — a transient read
error would otherwise flap levels on a live process; emptying it to `{}` is the
reset.
Signed-off-by: Cosmin Staicu <cosmin.staicu@uipath.com>