[Advanced]: Add CI Pipeline for Example Validation

## 🧠 Advanced Issue

This issue is designed for experienced contributors who are comfortable navigating unfamiliar systems, working with incomplete specifications, and making thoughtful design tradeoffs with long-term implications.

Advanced Issues may involve:
- Major architectural decisions or infrastructure changes
- Cross-cutting concerns that span multiple modules
- Creating new systems or frameworks
- Defining patterns others will follow

The best solutions will reflect care, clarity, and a deep understanding of the problem space.

---

## 🐞 Problem Description

The SDK has **55+ examples** in `src/sdk/examples/` that demonstrate various SDK features. Currently, these examples are:
- Built as part of the CMake project
- Not automatically tested in CI
- Manually runnable via `run_examples.sh`

There is no automated verification that examples work correctly with:
- New SDK releases
- Mainnet/network version updates

When examples break silently, users following documentation encounter runtime failures, damaging trust in the SDK.

---

## 💡 Expected Outcome

Create a CI pipeline that automatically runs SDK examples and reports pass/fail status.

**Goals:**
1. Examples are validated before SDK releases
2. Clear visibility when an example fails (BUILD ERROR vs BUILD SUCCESS)
3. Integration with existing CI infrastructure (GitHub Actions, solo)
4. Reasonable CI execution time

**Non-goals:**
- Changing example implementations (unless necessary for testability)
- Running examples against mainnet/testnet (use solo local network)

---

## 🧠 Design Considerations

Several architectural decisions need to be made:

### 1. Example Classification
Not all examples are equal:
- **Offline examples** (e.g., `GenerateKeyExample`, `VersionExample`) - no network needed
- **Network examples** (e.g., `CreateAccountExample`, `TransferCryptoExample`) - require solo
- **Long-running examples** (e.g., `ConsensusPubSubExample`) - may need timeouts

Consider creating a manifest or categorization system.

### 2. CI Integration Strategy
Options to consider:
- **New workflow file** - dedicated `flow-run-examples.yaml`
- **Extend existing workflow** - add step to `zxc-build-library.yaml`
- **Release-only workflow** - triggered on tags/releases

Current CI already:
- Builds the SDK
- Starts solo via `hiero-solo-action`
- Runs integration tests

### 3. Execution Approach
Options:
- **Sequential execution** - simple but slow (~55 examples)
- **Parallel execution** - faster but may hit network/resource limits
- **Selective execution** - run subset based on changes

### 4. Failure Handling
- Should one failing example fail the entire job?
- How to handle flaky examples?
- Timeout handling for hanging examples

### 5. Cross-Platform Considerations
Current CI supports:
- Linux (primary)
- Windows (optional)
- macOS (optional)

Should examples run on all platforms?

---

## 📂 Relevant Files

**Examples location:**
- `src/sdk/examples/` - 55+ example files
- `src/sdk/examples/CMakeLists.txt` - build configuration

**Existing CI:**
- `.github/workflows/flow-pull-request-checks.yaml` - PR checks
- `.github/workflows/zxc-build-library.yaml` - build/test pipeline

**Existing runner script:**
- `run_examples.sh` - basic sequential runner (not CI-integrated)

**Example build output:**
- `build//sdk/examples/` - compiled example binaries

---

## ✅ Acceptance Criteria

- [ ] CI pipeline runs SDK examples automatically
- [ ] Clear pass/fail reporting for each example
- [ ] Failed examples cause CI job to fail
- [ ] Pipeline runs before releases (or on release branches)
- [ ] Reasonable execution time (consider parallelization)
- [ ] Documentation updated with any new processes
- [ ] Design documented (which examples run when, categorization, etc.)

---

## 📋 Contribution Guide

To help your contribution go as smoothly as possible:

- [ ] Comment `/assign` to request the issue
- [ ] Wait for assignment
- [ ] Fork the repository and create a branch
- [ ] Propose a design in the PR description before implementing
- [ ] Implement the CI pipeline
- [ ] Test locally with `act` or similar tool if possible
- [ ] Sign each commit using `-s -S`
- [ ] Push your branch and open a pull request

Read [Workflow Guide](docs/training/workflow.md) for step-by-step workflow guidance.
Read [README.md](README.md) for setup instructions.

**Pull requests cannot be merged without `S` and `s` signed commits.**
See the [Signing Guide](docs/training/signing.md).

---

## 📚 Additional Context or Resources

**Current example count by category (approximate):**
| Category | Count | Network Required |
|----------|-------|------------------|
| Account operations | 15+ | Yes |
| Token operations | 10+ | Yes |
| Consensus/Topic | 5+ | Yes |
| Contract | 5+ | Yes |
| File operations | 5+ | Yes |
| Key generation | 5+ | No |
| Scheduling | 6+ | Yes |
| Utility | 5+ | Varies |

**Existing CI resources:**
- Solo action: `hiero-ledger/hiero-solo-action@v0.16.0`
- Build matrix: Linux (primary), Windows/macOS (optional)

If you have questions, the community is happy to help:

https://discord.com/channels/905194001349627914/1337424839761465364