fix: splunk_upgrade always evaluates true (list/string version comparison)

[tod-uma]

Summary

get_facts.yml's "Set current version fact" task builds splunk_current_version / splunk_current_build_hash with regex_search(regexp, '\1'). Ansible's regex_search filter always returns a list when a group reference is passed (see plugins/filter/core.py), so these facts end up as single-element lists, e.g. ['9.4.8'].

Commit 16fd108 ("change splunk_target_version to string") added | first to unwrap splunk_target_version for its install_splunk.yml consumer, but didn't update the "Set current version fact" task to match. The result: splunk_target_version != splunk_current_version compares a string to a list and is always True, so splunk_upgrade evaluates true on every run against an already-installed host (as long as build_location is set) — regardless of whether the installed version actually differs from the target.

Impact: an unconditional splunkd stop/start (and, when splunk.allow_upgrade is set, a full reinstall-check cycle) on every single converge against an already-installed host — not just on real upgrades.

Reproduced directly against ansible-core's regex_search filter, independent of any host: before the fix, '9.4.8' != ['9.4.8'] is True; after unwrapping with | first, it's False, as expected when the versions actually match.

The same commit also left a stale | first on splunk_target_version at "Determine if Splunk has preinstall checks" — that task pre-dates the source-level unwrap and expected splunk_target_version to still be a list. Post-16fd108, applying | first to the now-scalar string takes its first character ("9" instead of "9.4.8"), which fails the is version('9.4.0', '>=') check for every 9.x/10.x target. Removed the now-redundant | first there too.

Test plan

• Reproduced the type mismatch by calling ansible-core's regex_search filter directly (list vs. scalar), confirmed the fix resolves it
• ansible-lint clean of new issues (only pre-existing stylistic findings shared by the rest of the file)
• Live-tested against two already-installed hosts on a private fork/branch: splunk_upgrade now correctly evaluates false and the previously-unconditional splunkd restart no longer occurs, run after run
• Verified against a second, independent bug found alongside this one (reconcile_config_map_values's unconditional remove+reapply, filed separately) that the two are unrelated — this fix alone brings a steady-state converge from 4 changed tasks down to 2 (the remaining 2 are the separate bug)