feat(blocknode): decouple plugins PVC provisioning from plugins.names to support operator-managed plugin sources

## Summary

Since #913 (PR #931), the provisioner uses `plugins.names` as a single signal for two independent decisions:

1. **Whether to provision the plugins PVC/PV and inject `existingClaim`**
2. **Whether Maven should resolve plugins** (chart-level decision, not provisioner-level)

When `plugins.names` is empty, the provisioner skips the PVC entirely. But decision (2) is not the provisioner's concern — Maven runs inside the chart's `resolve-plugins` init container, driven purely by whether the chart sees a non-empty `plugins.names`. The provisioner does not control Maven and should not need to.

This coupling blocks operator use cases where the plugins PVC is needed but Maven should not run:

- An operator with a **custom baked image** (private plugins pre-baked) wants the provisioner to provision the PVC so their `blockNode.initContainers` init container can seed it from the image — without setting `plugins.names` (which would trigger Maven and conflict with the baked plugins).
- An operator doing **mixed-source plugins**: some official plugins resolved by Maven, others seeded from a private image or private artifact store by a custom init container. They want to control both sources independently.

## What the provisioner currently does

`Manager.managesPluginsStorage()` returns `true` iff `EffectivePluginsNamesEmpty()` is `false` — i.e. PVC is provisioned iff `plugins.names` is non-empty. These are treated as equivalent.

## Proposed change

Decouple the two decisions by adding a `--manage-plugins-pvc` flag (default: `auto`, matching current behaviour) to `block node install` and `block node upgrade`:

| Value | Behaviour |
|-------|-----------|
| `auto` (default) | Current logic: create PVC iff `plugins.names` is non-empty |
| `true` | Always create and inject the plugins PVC, regardless of `plugins.names` |
| `false` | Never create the plugins PVC, regardless of `plugins.names` |

With `--manage-plugins-pvc=true`, the operator gets a provisioner-managed PVC and is free to populate it entirely via `blockNode.initContainers` in their values file. The chart still gates Maven on `plugins.names` — the provisioner has no involvement in that decision.

## Example workflow this unlocks

```bash
# Operator has a baked image with private plugins.
# Provisioner creates the PVC; init container seeds it from the image; Maven is skipped.
solo-provisioner block node install \
--profile local \
--manage-plugins-pvc=true \
--values operator-values.yaml # plugins.names: "" (no Maven); custom initContainer seeds PVC
```

```yaml
# operator-values.yaml
plugins:
names: "" # skips chart's Maven resolver
blockNode:
initContainers:
- name: seed-from-image
image: my-registry/my-block-node:1.2.3
command: ["sh", "-c", "cp -R /opt/hiero/block-node/app-*/plugins/. /plugins-pvc/ && chmod -R a+rX /plugins-pvc"]
volumeMounts:
- name: plugins-storage
mountPath: /plugins-pvc
```

## Related

- #913 / PR #931 — introduced the `plugins.names`-empty → skip-PVC logic this builds on
- #912 / PR #922 — `--timeout` flag; similar pattern of exposing a previously implicit decision
- hiero-ledger/hiero-block-node chart feature: `blockNode.extraVolumeMounts` — companion chart change to mount the provisioner-managed (or emptyDir) PVC into the main container's plugins path
- hiero-ledger/hiero-block-node PR #3390 — CI workaround that prompted this analysis

Start at Manager.managesPluginsStorage() and EffectivePluginsNamesEmpty(), then trace flag plumbing for block node install and upgrade. Implement the auto, true, and false behaviors described in the table, preserving chart-side Maven gating, and verify that PVC creation and existingClaim injection follow the selected mode.

Written by the indexing model from the issue text.