fix(block-node): let an explicit --config file take precedence over deployed state

## Problem

`block node install|upgrade|reconfigure -c ./my-config.yaml` silently ignores most of
what the file declares once a release is deployed. The RSL precedence walk is
`Reality -> State -> UserInput -> Env -> Config -> Default`, so the persisted/live
release wins over the config file for every field whose selector locks on a deployed
release.

That is the right default for a bare invocation, where the config tier holds the
compiled-in `deps.*` constants (`pkg/config.globalConfig` is pre-populated with them and
`config.Initialize` only replaces it when a path is given). It is the wrong answer when
the operator pointed `-c` at a file on purpose: that file is a desired-state declaration,
not a fallback.

The behaviour is also inconsistent field by field, which makes it impossible to predict:

| Field | Config vs. deployed release today |
|---|---|
| `blockNode.historicRetention` / `recentRetention` | config wins (`retentionResolver`) |
| `blockNode.version` on `upgrade` | config wins (`chartVersionResolver`) |
| `blockNode.version` on `install` / `reconfigure` | **deployed release wins** |
| `blockNode.chart` | **deployed release wins** (`chartRefResolver`) |
| `blockNode.storage.*` | **deployed release wins**; config only fills gaps (`storageResolver`) |

Concretely: an operator edits `blockNode.storage.liveSize` and `blockNode.chart` in the
file they pass to `block node reconfigure -c`, the command reports success, and the Helm
release is re-applied with the values recorded in `state.yaml` instead. Nothing warns
them; the config edit just has no effect.

## Proposed fix

Treat an explicitly supplied `-c/--config` file as authoritative over the deployed
release, in the block-node BLL, keeping the RSL selectors untouched:

* Record in `pkg/config` whether `Initialize` loaded a real file, so the BLL can tell an
operator-supplied config from the compiled-in defaults. Without that gate, promoting
the config tier would make `deps.BLOCK_NODE_VERSION` overwrite the deployed chart
version on every bare `reconfigure`.
* In `resolveBlocknodeEffectiveInputs` (`internal/bll/blocknode/helpers.go`), after the
resolver has produced its effective values, let non-empty declarations from that file
override the ones the resolver took from the deployed release. Storage reuses the
existing `BlockNodeStorage.MergeFrom` cascade rather than re-deriving paths.

Resulting precedence for the affected fields:

```
CLI flag > SOLO_PROVISIONER_* env var > explicit -c file > deployed release > defaults
```

### Out of scope: release identity

`blockNode.namespace`, `blockNode.release` and `blockNode.chartName` stay locked to the
deployed release (`validatedStringResolver`). Redeclaring them does not reconfigure the
running release — it points Helm at a second one and orphans the first — so a config file
must not be able to do it by accident.

The guards that already exist keep the newly-effective values honest: `reconfigure`
refuses a storage-path change without `--purge-storage`, and `upgrade` still refuses a
downgrade.

## Acceptance

- [ ] With `-c file.yaml` declaring `blockNode.chart`, `blockNode.version` or
`blockNode.storage.*`, `install` / `upgrade` / `reconfigure` use the file's values
even when the release is deployed and `state.yaml` holds different ones.
- [ ] A CLI flag still beats the file, and a `SOLO_PROVISIONER_*` env var still beats the
file.
- [ ] Without `-c`, resolution is byte-for-byte unchanged: the deployed release keeps
winning over the compiled-in defaults.
- [ ] `blockNode.namespace`, `blockNode.release` and `blockNode.chartName` from the file
are still ignored for a deployed release.
- [ ] A config-driven storage-path change on `reconfigure` still fails with the
`--purge-storage` remediation rather than silently recreating PVs.
- [ ] `docs/dev/effective-value-resolution.md` and `docs/reference/configuration.md`
describe the explicit-config tier.

Start with pkg/config.Initialize and resolveBlocknodeEffectiveInputs in internal/bll/blocknode/helpers.go, then trace the install, upgrade, and reconfigure entry points and existing BlockNodeStorage.MergeFrom cascade. Verify explicit-file values override deployed state while CLI and SOLO_PROVISIONER_* values remain higher priority, bare invocations remain unchanged, identity fields stay locked, storage-path guards still apply, and both named documentation files describe the new tier.

Written by the indexing model from the issue text.