Create a CI pipeline to validate new block node releases as well as pre-releases

### Background

The default block node version is pinned in pkg/deps/deps.go (currently 0.29.0). When a new block node version is released on ghcr.io/hiero-ledger/hiero-block-node/block-node-server, we have no automated way to know if it works with solo-weaver until someone manually tests it or bumps the default.

### Goal

A nightly CI pipeline that validates compatibility with the latest block node releases before we bump the default version. This gives us early warning of breaking changes and confidence when upgrading.

### Scenarios to test

1. Fresh install with latest stable release — Run solo-provisioner block node install --chart-version on a clean VM and verify the block node comes up healthy.
2. Upgrade from default stable to latest stable release — Install with the current default version (0.29.0), then run solo-provisioner block node upgrade --chart-version and verify the upgrade succeeds.
3. Upgrade from default stable to latest pre-release — Same as above but upgrading to the latest pre-release tag. This catches regressions early before they land in a stable release.

### Implementation notes

- Trigger: schedule with a nightly cron (e.g. cron: '0 2 * * *')
- Runner: kvm-runner (same as existing integration tests in zxc-integration-test.yaml)
- VM setup: Reuse the existing QEMU/cloud-init approach from zxc-integration-test.yaml
- Version discovery: Query the OCI registry (ghcr.io/hiero-ledger/hiero-block-node/block-node-server) for the latest stable and pre-release tags
- The pipeline should report which block node version was tested and whether it passed/failed
- On failure, consider opening an issue or notifying via a channel so the team can investigate before the version is promoted to default

### Acceptance criteria

- Nightly workflow runs on schedule
- Fresh install of latest stable block node version is tested
- Upgrade from default stable → latest stable is tested
- Upgrade from default stable → latest pre-release is tested
- Test results are visible in GitHub Actions with the tested version clearly logged
- Failures are surfaced (notification, issue, or workflow summary)