Bare non-empty-string conditionals break under ansible-core 2.17.4 (~28 sites, 3 already fixed) #387

Summary

ansible-core 2.17.4 (what the self-hosted2 CI container actually runs) rejects a bare
non-empty string used directly as a when:/assert.that boolean condition, with:

[ERROR]: Task failed: Conditional result (True) was derived from value of type 'str' at
'.../integration_config.yml:334:31'. Conditionals must have a boolean result.

Older ansible-core implicitly truthy-tested a bare string ("non-empty string = true"),
which is the idiom used throughout this collection's integration tests
(- some_field as shorthand for "this field is present/non-empty"). This newer version
requires an explicit boolean.

This is a pre-existing compatibility gap, not something introduced by the Indy-lab
failover work (#383/#384/#385/#386) — it's been dormant because, until that work, no host
actually in rotation had a genuinely non-empty value flowing through one of these specific
checks during a real CI run. Restoring CI to the first real nested-vSNS hosts in a long time
is what surfaced it, three separate times:

• Fix bare-string when/assert conditionals rejected by ansible-core 2.17.4 #385 fixed 6 occurrences across 4 files, all keyed on sc_config[sc_host].sc_replication_dest_host
  or .features.version_update.next_version (static config values).
• vm_replication_info: fix remaining bare-string assert conditional #386 fixed 4 more in vm_replication_info's 10_vm_replication_info.yml, on live
  API-response fields (vm_name, remote_cluster).

What's left

A YAML-aware scan (walks every task's when: and every assert/ansible.builtin.assert
task's that: list, flags any bare dotted-path expression with no comparison operator,
filter, or is/in/and/or/not) found 27 more candidates across 14 files below.

Caveat, read before fixing any of these: this scan can only see the textual shape of
the expression, not its runtime type. The confirmed failures so far have all been on
STRING-valued fields. A few of these candidates (features.*.is_supported,
features.*.is_writable, features.version_update.old_update_status_present) are backed by
literal YAML True/False values in integration_config.yml.j2, so they may already be
real native booleans and not actually broken — but worth confirming empirically (run the
target; if it fails with the same "Conditionals must have a boolean result" message, it's
real) rather than assuming either way. The fix, where needed, is the same shape used in
#385/#386: replace the bare expression with an explicit boolean test, e.g.
sc_config[sc_host].sc_replication_dest_host → sc_config[sc_host].sc_replication_dest_host | length > 0
(prefer | length > 0/| length == 0 over | bool — Ansible's bool filter only
recognizes a fixed set of yes/no/true/false-style tokens and isn't guaranteed to treat an
arbitrary string, like a URL, the way you'd want).

Likely a real, active failure right now (not just a candidate) — .64's nested cluster
has sc_replication_dest_host genuinely configured, so remote_cluster_info's "If remote
cluster is configured" branch runs for real on it, same as vm_replication_info did before
#386:

• remote_cluster_info/tasks/main.yml (task with the assert.that block covering name,
  connection_status, replication_ok, remote_node_ips, remote_node_uuids) — 5 items

Full candidate list

(paths relative to tests/integration/targets/)

Suggested approach

1. Start with remote_cluster_info — near-certain active failure against the current fixture.
2. For the rest, the fastest way to separate real bugs from false positives is just running
   each target and seeing whether it fails with the same message, rather than reasoning about
   types statically.
3. Same fix shape as Fix bare-string when/assert conditionals rejected by ansible-core 2.17.4 #385/vm_replication_info: fix remaining bare-string assert conditional #386 once confirmed.

Found while restoring this collection's CI after the PUB5/XLab outage — see #383 for that
context.