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

**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