fix(mariadb): make switchover completion non-preemptive

[weicao]

Problem and observed evidence

This stacked PR now closes two addon-side parts of the MariaDB switchover contract.

1. Explicit candidates can converge after the action budget

Two independent runs showed the same shape:

• MariaDB 11.4.5: DCS request and old-primary fence closed, but the named candidate converged about 162 seconds later. The action exhausted its budget and returned rc=1 first.
• MariaDB 11.4.8: the candidate converged about 141 seconds later, again after the action had returned rc=1.

Evidence strength is 11.4.5 N=1 plus 11.4.8 N=1. It is not a frequency claim.

2. A second request must not preempt an unfinished DCS switchover

In the fresh r7 failure, syncer prepared and promoted the candidate at 07:20:58, but the addon saw secondary for 28 polls and Stage 5 returned rc=1. The first authoritative lease refresh appeared at 07:25:45 and the database write commit at 07:25:48.

The old addon always passed syncerctl switchover --force. That allowed a later request to delete an unfinished marker without proving that the previous lease, database, or grant changes had rolled back.

This evidence proves the circular completion timing at the old exact. It does not prove the new addon exact or the companion syncer patch at runtime.

Behavior changes

Candidate-mode completion

• Explicit candidate: after DCS acceptance and a positive old-primary fence, return structured convergence=delegated. The exact KubeBlocks controller keeps the OpsRequest Processing until that named candidate reports the expected role.
• Auto-selected candidate: retain Stage 5/6 candidate-role and remote-root readiness proof, then return convergence=observed. An empty CandidateName has no controller-side named-candidate role gate.
• Unknown candidate mode fails closed.

The internal action deadline remains 50 seconds under the 60-second ComponentDefinition timeout.

Non-preemptive in-flight handling

• Remove --force from both real syncerctl switchover invocations.
• Map syncer's stable SWITCHOVER_IN_PROGRESS response to outcome=retryable_conflict mutation=0.
• Return immediately on that proven conflict, before duplicate final-state probing or uncertain-DCS local fencing.
• If DCS was accepted but Stage 5/6 cannot prove terminal truth, report outcome=indeterminate_dcs_in_progress mutation=remote-partial; keep the old primary fenced.
• Keep the existing uncertain-DCS fence for all other non-zero/timeout responses, where persistence cannot be proven either way.

TDD and independent review

• Candidate-mode OLD RED: 3 examples / 2 failures.
• Idempotent-fence OLD RED: 3 / 3 failures, then 7 / 0 GREEN.
• New in-flight contract: initial selected set 7 / 3 RED, then 7 / 0 GREEN.
• Action-level mutation0 test: old implementation 1 / 1 RED, then 1 / 0 GREEN.
• Final switchover ShellSpec: 215 / 0 / 6 historical pendings.
• Final full MariaDB ShellSpec: 803 / 0 / 9 historical pendings.
• Bash/dash syntax, ShellCheck error severity, git diff --check, Helm lint and default render: PASS.
• GitHub checks on current head: 7 success / 0 failure.

Magnus independently fetched exact 44e415d930484146f5e7a61cecfa12b48fc50b80, reproduced focused 215/0/6, reproduced genuine base-script × new-spec RED 215/4, restored the head to 215/0/6, and reran the full 803/0/9 suite. Verdict: GREEN / CONFORMANT to design v3.

Review focus

Please focus on:

1. The three-way outcome split: proven pre-DCS conflict (mutation=0), unknown persistence (uncertain-DCS fence), and accepted-DCS but unproven terminal truth (remote-partial).
2. Whether any active-marker path can reach local final-state probing/fencing.
3. Whether explicit delegation still preserves the positive old-primary fence and auto mode still proves Stage 5/6.

Current boundary and merge order

• PR head: 44e415d930484146f5e7a61cecfa12b48fc50b80.
• Stacked base: PR fix(mariadb): make reconfigure loopback TLS mode explicit #3228 exact 8f1fcd78ffa564c8e356a8fc3b5f9c786a1bdeae.
• Runtime validation of this head: N=0. Test owns package, approved environment, evidence, counting, and cleanup.
• Companion syncer PR chore: add yashan db chart #313 is still under independent review. Its current head is source/unit GREEN only; cross-layer review found two syncer-side candidates still being falsified (CAS-race stable token and legacy missing-holder commit evidence).
• Therefore this PR is ready for addon code review, but it must not be described as an end-to-end runtime fix or used for Test handoff until the companion syncer exact is terminal and the combined source identity is re-frozen.

Design v3 SHA256: 24a2130cab43c6d401f75be4a2939ed0d30956a117bfbcdbe7eaa08f7a96f1d6.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 226 lines in your changes missing coverage. Please review.
✅ Project coverage is 0.00%. Comparing base (8f1fcd7) to head (44e415d).

Files with missing lines	Patch %	Lines
...adb/scripts-ut-spec/replication_switchover_spec.sh	0.00%	226 Missing ⚠️

Additional details and impacted files

@@                       Coverage Diff                       @@
##           helen/mariadb-r25-loopback-tls   #3229    +/-   ##
===============================================================
  Coverage                            0.00%   0.00%            
===============================================================
  Files                                 158     158            
  Lines                               24658   24863   +205     
===============================================================
- Misses                              24658   24863   +205     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.