fix(rabbitmq): derive restore archive stem from target path

[weicao]

Problem

Volume-populator restore supplies DP_TARGET_RELATIVE_PATH as <target-name>/<target-pod-name>. DP_BACKUP_BASE_PATH is already scoped to that relative path. Treating the full relative path as the archive stem makes restore look for <target-name>/<target-pod-name>.tar.zst inside the per-target base path, while backup writes <target-pod-name>.tar.zst.

This addresses the current human review blocker on #3113 without changing the backup artifact layout.

Fix

• Prefer DP_TARGET_POD_NAME when the backup/restore job provides it.
• Otherwise require exactly <target-name>/<target-pod-name> and derive only the final pod-name segment.
• Fail closed when the relative path has no target or pod segment, or has extra path segments.
• Keep DATASAFED_BACKEND_BASE_PATH equal to the injected DP_BACKUP_BASE_PATH.
• Update the contract test to use the actual <target>/<pod> shape and assert both base path and archive key.

Validation

• RED before implementation: focused ShellSpec looked for rabbitmq/rmq-br-5400-rabbitmq-2.tar.zst.
• Additional RED: rabbitmq/ was incorrectly accepted as archive stem rabbitmq before the fail-closed guard.
• GREEN after implementation: focused RabbitMQ backup/restore ShellSpec, 15 examples / 0 failures.
• shellcheck addons/rabbitmq/dataprotection/restore.sh
• bash -n addons/rabbitmq/dataprotection/restore.sh
• git diff --check

Runtime B/R evidence is intentionally not claimed by this static fix; the exact repinned candidate still needs same-identity backup/restore validation.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (b89b237) to head (52ff725).

Additional details and impacted files

@@                      Coverage Diff                       @@
##           jasper/rabbitmq-candidate-base   #3183   +/-   ##
==============================================================
  Coverage                            0.00%   0.00%           
==============================================================
  Files                                 145     145           
  Lines                               23153   23153           
==============================================================
  Misses                              23153   23153           

☔ 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.

[weicao]

Runtime blocker on the integrated exact candidate f48116a58a7482a96445ae63f4c397ad5f72e53d (single full run, same topology; three PVCs in that run).

Run: combined-full-f48116a5-fce8f608-20260713T203014Z
Result: PASS=396 FAIL=1 SKIP=12; sole FAIL was B/R T05.

Direct restore Job evidence for all three target PVCs:

• KB 1.2 volume-populator injected a single-segment value, e.g. DP_TARGET_RELATIVE_PATH=rmq-br-1974-rabbitmq-2.
• DP_BACKUP_BASE_PATH was already fully scoped to .../rmq-br-1974-rabbitmq-2.
• the restore container exited 1 before datasafed pull with ERROR: DP_TARGET_RELATIVE_PATH must be <target-name>/<target-pod-name>.
• each Job reached BackoffLimitExceeded; each Restore kept phase AsDataSource with condition reason Failed.

This disproves the PR's two-segment runtime assumption for this exact KB 1.2 path. The parent implementation at 0c027e5d accepted the single-segment DP_TARGET_RELATIVE_PATH directly as the archive stem; that is the smallest correction for the observed contract. Please do not reuse 52ff725f or integrated f48116a5 as a runnable B/R candidate without a corrective exact SHA.

Full artifact SHA256: bd83529ae8d00af3a6bc6544e687ea1abd96d539d52f11697cf490327f835a41 (task #81 thread attachment). A separate tests PR, apecloud/kubeblocks-tests#772, only fixes fail-fast detection and does not change the addon verdict.