[FEATURE] Consider a reusable mechanism for shared open-file lifetime management

### Is your feature request related to a problem? Please describe.

This issue was identified while fixing [#20037](https://github.com/apache/nuttx/issues/20037), where the FAT filesystem could release a file's cluster chain when the file was unlinked while still open.

The FAT fix in [#20101](https://github.com/apache/nuttx/pull/20101) introduced filesystem-local shared state to track the lifetime of an open file independently of individual file descriptors.

While investigating the same lifetime semantics across other filesystems, I found that NuttX currently has no common mechanism for filesystems that require shared open-file state:

- **tmpfs** already maintains shared per-file state with reference counting and an unlinked state, and correctly defers reclamation until the last reference is released.
- **littlefs** handles removal of open files through its existing copy-on-write and orphan handling mechanisms and does not appear to require such an abstraction.
- **NFS** appears to have a related lifetime-management gap: open state is maintained per `open()` operation, while removal is performed immediately without a shared open-file lifetime mechanism or silly-rename handling.

This suggests that open-file lifetime management is currently implemented independently by each filesystem, with no reusable mechanism for filesystems that need shared state across open, `dup()`, unlink, and close operations.

### Describe the solution you'd like

I would like to explore an **opt-in mechanism for shared open-file lifetime management** that can be used by filesystems that require it, without making it a mandatory part of the VFS.

The common pattern could provide a shared per-filesystem object that is looked up or created when a file is opened, reference-counted across `open()` and `dup()`, marked for deferred deletion when the file is unlinked, and reclaimed when the final reference is released.

The exact API, ownership model, and placement are intentionally left open for discussion. The `fat_shared_s` implementation introduced in [#20101](https://github.com/apache/nuttx/pull/20101) provides a concrete example of this lifetime-management pattern, while NFS appears to be a potential second use case.

The mechanism should remain optional so that filesystems that already manage object lifetime correctly do not need to adopt it, and filesystems that do not use it should not incur additional `struct file`, RAM, or runtime overhead.

If this direction is considered useful, I would be happy to prototype a minimal implementation and evaluate it with an additional filesystem.

### Describe alternatives you've considered

- **Continue implementing lifetime management independently in each filesystem.** This avoids introducing a common abstraction, but requires each filesystem to independently solve the same open, `dup()`, unlink, and final-close lifetime problems.

- **Introduce a mandatory generic inode/object cache in the VFS.** This would provide a common mechanism, but appears broader than necessary. `tmpfs` and `littlefs` demonstrate that filesystems can already provide correct lifetime semantics using their own internal models. Making such infrastructure mandatory could also impose unnecessary memory or runtime costs on small targets.

- **Keep the current FAT-local implementation and address other filesystems independently.** This is viable, but the experience from #20037/#20101 suggests there may be value in identifying a small reusable abstraction for filesystems that encounter the same class of lifetime-management problem.

### Verification

- [x] I have verified before submitting the report.

Start by reading the FAT shared-state implementation introduced in #20101, then compare the existing lifetime handling in tmpfs and NFS, especially across open, dup(), unlink, and close. Done means proposing or prototyping an optional reusable mechanism with a clear API and ownership model, and evaluating it with an additional filesystem.

Written by the indexing model from the issue text.