lock metric reads in Store.Gc and json marshal to fix data race

[sayed0200]

mtail turns captured log fields into metric label values, and a new label-value tuple gets appended to Metric.LabelValues under the metric write lock inside GetDatum every time a program sees one it has not recorded before. The periodic Store.Gc loop and Metric.RemoveOldestDatum walk that same slice to trim expired or over-limit entries, but they hold only the store search lock, never the metric own lock, so a GC tick racing with a steady stream of fresh labels from the logs is a real data race on the slice header that go test -race reports. The default reflection marshalling of a Metric reads LabelValues the same unlocked way, so scraping /json or /debug/vars while the VM is updating metrics trips it too, and a torn read of the header can index past the backing array rather than just return stale data. I ran into it driving a writer that adds labels against the store tests under the race detector. The fix reads LabelValues under m.RLock() in Gc and RemoveOldestDatum, collecting the entries to drop and releasing the lock before the Remove* helpers reacquire it as writers, and adds a Metric.MarshalJSON that takes the read lock and marshals through a method-less alias so the output stays byte-identical. A -race regression test runs GetDatum against Gc and MarshalJSON concurrently.