Add unsupported setting warning: warn users when configuring settings that have no effect on their variant

[ytsssun]

What I'd like:

An unsupported setting warning mechanism that alerts users when they configure a setting that has no effect on their variant. For example, container-runtime.max-concurrent-unpacks is only supported on containerd 2.2+, but a user can set it on a containerd 1.7 variant without any indication that it's being ignored. The same applies to Kubernetes settings that are version-specific.

We attempted this in #886 with a systemd timer/service (unsupported-setting-warning@) that would periodically log a journal warning. We removed it in #912 because the implementation hit a fundamental issue: the defaults wiring (affected-services, configuration-files) is shared across all variants, but the template files are packaged per component version. This caused thar-be-settings to fail in strict mode on variants where the setting is supported, since the "unsupported" template file didn't exist there. The workaround of carrying empty template files in supported versions doesn't scale — each new version-gated setting would require empty templates across all other package versions.

Any solution needs to handle the fact that:

• defaults.toml is shared across variants that may ship different component versions
• thar-be-settings strict mode must not break when a user sets a valid setting
• The mechanism should scale to multiple settings across multiple components (not just containerd)

Any alternatives you've considered:

• Variant-level defaults wiring (requires plumbing work since shared defaults aren't scoped per component version today)
• An optional flag on configuration-files in the settings model so missing templates don't fail strict mode