NOTE: This bug is Critical because it blocks API promotion of Two Nodes with Fencing to Default

Description of problem:
The E2E test "should recover from BMC credential rotation with fencing" fails in dualstack CI lanes
(periodic-ci-openshift-release-main-nightly-4.22-e2e-metal-ovn-two-node-fencing-dualstack-recovery-techpreview)
but passes in IPv4-only lanes.

The test's RotateNodeBMCPassword function in test/extended/two_node/utils/apis/baremetalhost.go searches for
BMC secrets in openshift-machine-api by checking if the secret name contains the node name:

if strings.Contains(s.Name, node.Name) && strings.Contains(s.Name, "bmc") {

In dualstack environments, Kubernetes node names are FQDNs (e.g. "master-0.ostest.test.metalkube.org"),
while BMC secrets use short hostnames (e.g. "openshift-master-0-bmc-secret"). The FQDN is never a
substring of the shorter secret name, so the lookup fails.

In IPv4-only environments, node names are short hostnames (e.g. "master-0"), so the substring check succeeds.

Version-Release number of selected component (if applicable):
4.22.0-0.nightly-2026-02-08-124411

How reproducible:
100% in dualstack lanes. Every run of the dualstack-recovery-techpreview periodic job fails this test.
IPv4-only lanes are not affected.

Steps to Reproduce:
1. Run the periodic job periodic-ci-openshift-release-main-nightly-4.22-e2e-metal-ovn-two-node-fencing-dualstack-recovery-techpreview
2. Observe the test "[sig-etcd][OCPFeatureGate:DualReplica][Suite:openshift/two-node][Serial][Disruptive] Two Node with Fencing etcd recovery should recover from BMC credential rotation with fencing"
3. Test fails during precondition phase before any BMC rotation is attempted

Actual results:
fail [github.com/openshift/origin/test/extended/two_node/tnf_recovery.go:348]: expected to rotate BMC credentials without error
Unexpected error:
<*errors.errorString | 0xc001581e40>:
no BMC secret found for node master-0.ostest.test.metalkube.org

Expected results:
The test should find the BMC secret regardless of whether node names are short hostnames or FQDNs,
and the BMC credential rotation + fencing recovery should complete successfully.

Additional info:
Failing dualstack job: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/periodic-ci-openshift-release-main-nightly-4.22-e2e-metal-ovn-two-node-fencing-dualstack-recovery-techpreview/2022933666442776576
Passing IPv4 job: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/periodic-ci-openshift-release-main-nightly-4.22-e2e-metal-ovn-two-node-fencing-recovery-techpreview/2021167094200012800

Bug location: test/extended/two_node/utils/apis/baremetalhost.go lines 87-89 (RotateNodeBMCPassword)

Fix: Extract the short hostname from node.Name before matching (split on "." and use the first segment),
or look up the BMC secret via the BareMetalHost spec.bmc.credentialsName field.

Note: The node replacement test already handles this correctly using regex-based matching
via findObjectByNamePattern in test/extended/two_node/tnf_node_replacement.go:1541.

All other TNF tests (11 of 12) pass in the same dualstack job — this is isolated to the
BMC credential rotation test's secret lookup logic.