fix: reconcile_config_map_values unconditionally removes+reapplies every option

[tod-uma]

Summary

remove_config_map_stanza.yml unconditionally issued ini_file state=absent for every option recorded in the previous .<conf_file>.splunk-ansible-managed.yml state file, then set_config_stanza.yml immediately re-added every currently-desired option with ini_file state=present. In steady state (group_vars unchanged between runs) this deletes and recreates the identical option on every single converge — ini_file correctly reports changed: true for both the removal (the option existed) and the re-add (it was just removed), even though the net file content never moves.

This is a distinct bug from #931 (the splunk_upgrade list/string comparison) — confirmed independently by re-testing #931's fix alone against two hosts, twice each: the splunkd restart pair was gone and the runs were deterministic, but a steady changed=2 remained, always attributable to these same two reconcile tasks.

Fix

Only remove an option if it is no longer present in the current desired stanza (conf_stanzas, already in scope via set_config_file.yml's include vars) — i.e. only prune options actually dropped from group_vars. An option that's still desired, even with a changed value, is left for set_config_stanza.yml's existing idempotent ini_file state=present to update in place, which already no-ops correctly when the value hasn't changed.

Test plan

• Verified the new when condition offline against three cases before touching a host: steady state (no removal), one key dropped from group_vars (only that key pruned), whole stanza dropped (all its keys pruned)
• ansible-lint clean of new issues (pre-existing risky-file-permissions finding on this file predates this change, confirmed via git stash)
• Live-tested against two hosts on a private fork/branch, each run twice: steady-state converges now report changed=0 on user-prefs.conf's ConfigMap-owned reconcile, down from 2 changed tasks every run