[Beginner]: Add error-path tests for `swapStatusLabel`

### 🐥 Beginner Friendly

This issue is a great fit for contributors who are ready to explore the Hiero C++ codebase a little more and take on slightly more independent work.

Beginner Issues often involve reading existing C++ code, understanding how different parts of the SDK fit together, and making small, thoughtful updates that follow established patterns.

The goal is to support skill growth while keeping the experience approachable, well-scoped, and enjoyable.

> [!IMPORTANT]
> ### 🐥 About Beginner Issues
>
> Beginner Issues are a great next step for contributors who feel comfortable with the basic project workflow and want to explore the codebase a little more.
>
> These issues often involve:
> - Reading existing C++ code
> - Understanding how different parts of the SDK fit together
> - Making small, thoughtful updates that follow established patterns
>
> You'll usually see Beginner Issues focused on things like:
> - Small, well-scoped improvements to existing tests
> - Narrow updates to `src` functionality (e.g. refining helpers or improving readability)
> - Documentation or comment clarity
> - Enhancements to existing examples
>
> Other types of contributions — such as brand-new features, broader system changes, or deeper technical work — are just as valuable and may use different labels.

### 👾 Description of the Task

PR #1527 fixed `swapStatusLabel` so it surfaces errors instead of silently swallowing them. The fix landed with happy-path tests only — the existing six `swapStatusLabel` tests verify side-effects on success but do not exercise the new error-return surface.

> Maintainer comment on PR #1527: *"the six existing `swapStatusLabel` tests only verify happy-path side-effects and don't check the new return value when an operation fails. Since surfacing those errors is the whole point of this fix, a couple of error-path tests would prevent a future regression… Happy to merge as-is if you'd prefer to save this for a follow-up!"*

The follow-up was never filed. Verified at the v0.55.0 release commit: `.github/scripts/tests/test-api.js` lines 614–687 contain only six happy-path `swapStatusLabel` tests; no mock makes `removeLabel` or `addLabels` throw, and no test asserts the function's `errorDetails` / `success: false` shape.

Relevant files:

```
.github/scripts/tests/test-api.js
.github/scripts/helpers/ (whichever file actually defines swapStatusLabel)
```

### 💡 Proposed Approach

Add at least two error-path tests to `test-api.js` that follow the exact same shape and naming conventions as the existing happy-path tests:

1. A test where the mocked `removeLabel` throws — assert that `swapStatusLabel` returns the failure shape (e.g. `{ success: false, errorDetails: }` — match whatever the actual fix's return shape is) and that `addLabels` is _not_ called (because the remove failed first).
2. A test where `removeLabel` succeeds but `addLabels` throws — assert the failure shape and that `removeLabel` _was_ called.

If the implementation distinguishes between transient and permanent failures (e.g. retries on 500 but not on 404), add one test per category.

### 👩‍💻 Implementation Steps

- [ ] Read [.github/scripts/tests/test-api.js](../../.github/scripts/tests/test-api.js) lines 614–687 (the existing `swapStatusLabel` tests) and learn the test runner's mock + assert helpers.
- [ ] Open the implementation of `swapStatusLabel` (find via `grep -rn "function swapStatusLabel" .github/scripts/`) and confirm exactly which return shape it produces on failure today (post-PR #1527).
- [ ] Add an error-path test where the mocked `removeLabel` throws. Assert the failure return shape and that `addLabels` is not invoked.
- [ ] Add an error-path test where `removeLabel` succeeds and `addLabels` throws. Assert the failure return shape and that `removeLabel` _was_ invoked.
- [ ] Add a third test only if there is a meaningful additional branch (e.g. an explicit transient-error retry path). If there is not, two tests are enough.
- [ ] Run the full bot-script test suite and confirm everything (including the new tests) passes.
- [ ] If the migration to Jest (separate follow-up issue) is in flight when you start, write the new tests in whichever style is current — don't try to dual-write.

### ✅ Acceptance Criteria

- [ ] At least two new error-path tests exist for `swapStatusLabel`.
- [ ] Each test mocks the underlying `removeLabel`/`addLabels` calls to throw and asserts the documented failure return shape.
- [ ] All previously-passing tests still pass.
- [ ] No production logic in `swapStatusLabel` is modified — this is a tests-only PR.

---

### 📋 Step-by-Step Contribution Guide

To help keep contributions consistent and easy to review, we recommend following these steps:

- [ ] Comment `/assign` to request the issue
- [ ] Wait for assignment
- [ ] Fork the repository and create a branch
- [ ] Set up the project using the instructions in `README.md`
- [ ] Make the requested changes
- [ ] Sign each commit using `-s -S`
- [ ] Push your branch and open a pull request

Read [Workflow Guide](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/docs/training/workflow.md) for step-by-step workflow guidance.
Read [README.md](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/README.md) for setup instructions.

❗ Pull requests **cannot be merged** without `S` and `s` signed commits.
See the [Signing Guide](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/docs/training/signing.md).

### 🤔 Additional Information

- Originating PR: [#1527](https://github.com/hiero-ledger/hiero-sdk-cpp/pull/1527).
- Closing issue from that PR: [#1441](https://github.com/hiero-ledger/hiero-sdk-cpp/issues/1441) (closed).

If you have questions while working on this issue, feel free to ask! [Hiero-SDK-C++ Discord](https://discord.com/channels/905194001349627914/1337424839761465364)

Read .github/scripts/tests/test-api.js lines 614–687 and find swapStatusLabel with grep under .github/scripts/helpers/. Follow the existing mock and assertion patterns, then run the full bot-script test suite. Done means adding two error-path tests covering failures in removeLabel and addLabels, including the failure return shape and call behavior, without changing production logic.

Written by the indexing model from the issue text.