cephfs: cephFS.radosNamespace is not applied consistently

# Describe the feature you'd like to have #

The csi-config option `cephFS.radosNamespace` (default `csi`) names the RADOS namespace in the metadata pool that holds every
object Ceph-CSI creates for a CephFS cluster. Several code paths bypass it and read or write the default namespace of the
metadata pool instead, or ignore the option entirely. I would like `cephFS.radosNamespace` to be applied consistently, so
that all Ceph-CSI state for a cluster lives in the configured namespace.

Known instances of the inconsistency (the list may be incomplete):

- [x] The RADOS lock that serializes fscrypt setup for encrypted volumes lives in the default namespace of the metadata
pool (`internal/cephfs/nodeserver.go`, `maybeUnlockFileEncryption`).
- [ ] Static (pre-provisioned) volumes never receive the namespace. `NewVolumeOptionsFromStaticVolume`
(`internal/cephfs/store/volumeoptions.go`) copies `ClusterID`, `Monitors`, and `SubvolumeGroup` from
`GetClusterInformation()` but not `RadosNamespace`, even though `GetClusterInformation()` resolves it, so the field
stays empty. Today nothing on the static node path consumes the field, so the gap is latent.
- [ ] Volumes built from a monitor list (`NewVolumeOptionsFromMonitorList`, the legacy pre-csi-config fallback) also leave
the namespace empty. Since this path is legacy, is a change needed here at all?
- [ ] The NFS driver never resolves `cephFS.radosNamespace` itself. Provisioning is delegated to the CephFS backend, which
honors the configured namespace for the reservation omaps, but the NFS-specific attributes (`nfs.cluster`, `server`)
are written through journal connects that pass the package-level default (`fsutil.RadosNamespace`, initialized to
`csi`; `internal/nfs/types/volume.go`). On a cluster with `cephFS.radosNamespace` not set to `csi`, the volume's
journal entries therefore end up in two RADOS namespaces: the reservation omaps in the configured one, and the NFS
attributes on a same-named object in `csi`.

# What is the value to the end user? (why is it a priority?) #

This came out of work on minimizing the CephX caps of the Ceph-CSI node client. Everything the nodeplugin does in the
metadata pool is meant to be confined to `cephFS.radosNamespace`, so its OSD caps could be scoped to that namespace. The
bypassing paths above are what prevents that today because of them the node caps need to include the full metadata pool.
With the inconsistencies fixed, operators can grant namespace-scoped caps, and they can rely on the configured namespace
containing all Ceph-CSI state, for inspection, monitoring, and cleanup.

# How will we know we have a good solution? (acceptance criteria) #

* Every RADOS object Ceph-CSI creates or reads for a CephFS cluster lives in `cephFS.radosNamespace`, including the fscrypt
lock, the objects of static volumes, and the journals of the NFS driver.
* A nodeplugin whose OSD caps are scoped to `cephFS.radosNamespace` can perform every node operation, mounting encrypted
volumes included.
* Rolling upgrades from releases that use the default namespace stay safe while both versions run.
* A decision is recorded for the legacy monitor-list path.

# Additional context #

## Core Question

To the maintainers: is making `cephFS.radosNamespace` consistent across these paths something you want fixed? If this is not
a goal for the project, please say so and the issue can be closed.

## Overall Plan
Plan: the instances are independent, so if you want this fixed I will open a separate PR for each checklist item, keeping
every change small and reviewable.

Read internal/cephfs/nodeserver.go's maybeUnlockFileEncryption and internal/cephfs/store/volumeoptions.go's NewVolumeOptionsFromStaticVolume first, then trace NewVolumeOptionsFromMonitorList and internal/nfs/types/volume.go. Check how each path resolves and passes cephFS.radosNamespace, including the legacy-path decision. Done means all listed CephFS objects, locks, static volumes, and NFS journals use the configured namespace and node operations work with namespace-scoped caps during upgrades.

Written by the indexing model from the issue text.