Validate S3 credentials for Block Node

### Summary

When provisioning a Block Node, the `values.yaml` configuration may include S3-related settings
that define how the node uploads blocks to an S3-compatible bucket. These settings reference a
Kubernetes `secretRef` for credentials, as seen in
[`rfh-values.yaml`](https://github.com/hiero-ledger/hiero-block-node/blob/1d3c01d1725fb8d8b9263b8c6fb4c8cac76e5eda/charts/block-node-server/values-overrides/rfh-values.yaml#L7).

If those credentials are missing, malformed, or invalid, the Block Node will fail silently or
produce hard-to-diagnose errors at runtime — potentially long after provisioning has completed.

Solo-provisioner should detect and surface these issues **before** the node is deployed, failing
fast with clear and actionable error messages.

---

### Motivation

Node operators who configure S3 block uploads expect that once provisioning succeeds, the pipeline
is working end-to-end. Without pre-flight checks, a misconfigured secret or unreachable bucket
won't surface until the node actually attempts to push a block, making it difficult to distinguish
an infrastructure problem from a node misconfiguration.

Failing early — at provision time — gives the operator an unambiguous signal and a much shorter
feedback loop.

---

### Proposed Checks

When S3-related values are detected in the Block Node configuration (i.e. a `secretRef` is
specified for S3 upload), solo-provisioner should run the following pre-flight validations in order:

#### 1. Kubernetes Secret Existence

Verify that the Kubernetes `Secret` referenced by `secretRef` exists in the target namespace.

- Use the Kubernetes API to look up the secret by name and namespace
- Fail with a clear error if the secret is not found, e.g.:
[error] S3 secret "my-s3-secret" not found in namespace "solo".
Please create the secret before provisioning.

#### 2. Kubernetes Secret Format

Verify that the secret contains the expected keys required to connect to S3.

Expected keys (to be confirmed against the block node's actual requirements):

| Key | Description |
|---|---|
| `accessKeyId` | AWS / S3-compatible access key ID |
| `secretAccessKey` | AWS / S3-compatible secret access key |
| `bucketName` | Target S3 bucket name |
| `region` | AWS region (if applicable) |
| `endpoint` | Custom endpoint URL (for S3-compatible stores) |

- Fail with a clear error listing any missing keys, e.g.:
```
[error] S3 secret "my-s3-secret" is missing required keys: [region, endpoint].
Please update the secret before provisioning.
```

#### 3. Bucket Connectivity and Credential Validation

Using the credentials resolved from the secret, attempt to connect to the configured S3 bucket and
verify that the credentials are authorized.

- Perform a lightweight operation such as `HeadBucket` (AWS SDK) or equivalent
- This confirms both network reachability and credential validity
- Fail with a clear error if the connection cannot be established, e.g.:

```
[error] Unable to reach S3 bucket "my-bucket" using the credentials in "my-s3-secret".
Response: 403 Forbidden. Please verify the credentials and bucket permissions.
```

---

### Behaviour

- These checks should **only run when S3 values are present** in the Block Node configuration.
They should be a no-op when S3 upload is not configured.
- Checks should run as part of the existing provisioning pre-flight phase, before any Helm
install/upgrade is attempted.
- All three checks should be surfaced as errors (not warnings), as a node that cannot reach its
configured S3 bucket is not considered successfully provisioned.

---

### Out of Scope

- Validating S3 credentials for services other than Block Node
- Checking bucket policies beyond basic connectivity (e.g. ACLs, lifecycle rules)
- Ongoing credential health monitoring post-provisioning

---

### Acceptance Criteria

- [ ] When a Block Node `values.yaml` references an S3 `secretRef`, solo-provisioner checks that
the Kubernetes secret exists in the target namespace
- [ ] Solo-provisioner validates that the secret contains all required keys
- [ ] Solo-provisioner attempts a `HeadBucket` (or equivalent) operation using the resolved
credentials and fails early if the bucket is unreachable or returns an auth error
- [ ] All validation errors produce clear, actionable messages that tell the operator exactly what
to fix
- [ ] No S3 validation is performed when S3 upload is not configured in the Block Node values