cephfs: remove the transitional legacy fscrypt lock

This is a tracker to remove the transitional fscrypt lock that #6539 adds for rolling upgrades. Support can be removed in v3.19, since v3.18 already implements this transitional fscrypt lock.

Once upgrades from releases that take the lock in the default namespace are no longer supported, the
transitional default namespace lock serializes against nothing and can go.

- [ ] `acquireLegacyEncryptionLock` and its call in `maybeUnlockFileEncryption`
(`internal/cephfs/nodeserver.go`), leaving only the lock taken in `cephFS.radosNamespace`.
- [ ] The e2e assertion that the lock object also exists in the default namespace (`e2e/cephfs.go`, "verify
the fscrypt lock is taken in the CephFS RADOS namespace"). The assertion for the `cephFS.radosNamespace`
lock may stay.
- [ ] A note in `PendingReleaseNotes.md` for the release that drops it.

## Acceptance criteria ##

* Staging an encrypted volume takes exactly one RADOS lock, in `cephFS.radosNamespace`.
* The removal lands in a release whose supported upgrade sources all take the lock in `cephFS.radosNamespace`.

Start with internal/cephfs/nodeserver.go, locating acquireLegacyEncryptionLock and maybeUnlockFileEncryption, then inspect the named CephFS e2e assertion in e2e/cephfs.go. Check the release-note conventions in PendingReleaseNotes.md and run the relevant CephFS e2e coverage. Done means encrypted-volume staging takes only the cephFS.radosNamespace lock, the default-namespace assertion is removed, and a release note is added.

Written by the indexing model from the issue text.