Fix race condition in WithLazy implementation (#1426)

[jquirke]

Summary

• Fixes race condition in WithLazy implementation that occurred when multiple goroutines accessed Enabled() method
• Removes embedded Core from lazyWithCore struct and replaces with explicit delegate methods
• Adds regression test to prevent future race conditions

Problem

Issue #1426 reported a data race in Zap's WithLazy implementation where the embedded Core methods like Enabled() performed unsynchronized reads, causing race conditions when used across multiple goroutines.

The race occurred because:

1. lazyWithCore embedded a Core interface, making Enabled() directly accessible
2. Multiple goroutines could call Enabled() while another goroutine was calling initOnce()
3. The initOnce() function replaced d.Core with a new Core, creating a data race

Solution

Implemented @jquirke's suggested approach of returning new Core instances rather than using atomic operations:

1. Removed embedded Core: Changed from embedded Core to explicit core Core field
2. Added explicit delegate methods: Implemented Enabled(), Write(), Sync() methods that call initOnce() before delegation
3. Maintained API compatibility: No breaking changes to public interfaces
4. Thread-safe initialization: All methods ensure initialization before accessing the core

Test Plan

• All existing tests pass
• Race detection tests pass with -race flag
• Added TestLazyCoreRace regression test that fails before fix and passes after
• Verified concurrent access to Enabled() and other Core methods works without races

Performance Impact

• Minimal: The fix adds a small overhead of method calls but eliminates atomic operations
• Memory allocation is similar to existing patterns (e.g., With() already returns new Cores)
• Modern Go GC handles the short-lived allocations efficiently
• Benchmarks show no regressions: WithLazy performance maintained

🤖 Generated with Claude Code