fix(log): allow disabling the zap duplicate-message sampler

[armru]

The controller-runtime zap builder installs a sampler on every production-mode logger: only the first 100 messages sharing the same (level, message) pair each second get through, and roughly 1 in 100 afterwards. That is the right default for an operator, where a reconciliation storm can repeat the same message beyond any useful rate, but it is wrong for processes whose output must be complete. The CloudNativePG instance manager forwards every PostgreSQL log record with a constant message, so a burst of database activity (for example pgaudit under load) is silently collapsed by the sampler and most records never reach the pod's log stream (see cloudnative-pg/cloudnative-pg#10815).

This adds an optional WithDisabledSampling() argument to Flags.ConfigureLogging. The builder only installs the sampler when the configured level does not enable zapcore.Level(-2), so the option passes a fully-verbose level to make the builder skip it and then restores the level the user asked for by filtering the core with zap.IncreaseLevel. Everything else stays in the controller-runtime builder's hands (encoder, --zap-* flags, destination), so the unsampled logger's output is identical to the default one. Callers that don't pass the option keep the sampler exactly as before.

The new specs in pkg/log/flags_test.go exercise the real path, from flag parsing through ConfigureLogging to the --log-destination file: the default stays sampled, a 300-message burst is fully emitted with the option, --log-level filtering still applies, the trace level (where the builder never installs a sampler) keeps working, and the field-remapping flags are honored. The burst spec doubles as a tripwire if a future controller-runtime bump changes how the sampler is installed.

[armru]

/test