fix: lazily initialise Viper maps so zero-value struct does not panic

[SAY-5]

What

Fixes #2111.

A Viper instance constructed via a struct literal (&viper.Viper{}) rather than viper.New() has all of its internal string-keyed maps as nil. SetDefault and Set eventually dispatch to deepSearch, which assigns into those maps via map[key] = value and panics at runtime with assignment to entry in nil map.

Because Viper is an exported struct type, users following normal Go conventions for zero values (sync.Mutex{}, bytes.Buffer{}, strings.Builder{}, and so on) reasonably expect the zero value to either work or error - not panic with an internal implementation detail message.

Fix

Add an ensureMaps helper that lazily allocates defaults, override, config, kvstore, pflags, env, and aliases, and sets keyDelim to its . default if zero. Call it from SetDefault and Set before any map touch. Instances that went through New are already fully populated, so ensureMaps is a no-op for them and the hot path for existing callers is unchanged.

Tests

Added TestZeroValueStructSetDefaultNoPanic and TestZeroValueStructSetNoPanic. Both construct &Viper{} directly, call the mutator on dotted keys, and assert no panic fires and the stored values are readable back via Get. On master the Set test fails (nested.key never resolves because the stored value never reaches the zero-initialised map); after the fix both pass.

Verification

Locally on macOS, go 1.26.2:

• gofmt -s -l: clean
• go vet ./...: clean
• go test -race -count=1 -run 'TestDefault|TestZeroValueStruct' ./...: pass

Closes #2111

[CLAassistant]

All committers have signed the CLA.