Feature proposal: NFD Network Topology Updater

**What would you like to be added**:

Add an optional NFD feature for publishing cluster network topology through NFD
custom resources. The feature would introduce a new component named
`nfd-network-topology-updater`, responsible for discovering network fabric
topology, mapping fabric objects back to Kubernetes nodes, and keeping the
corresponding NFD objects up to date.

The initial publication model should create:

- one managed `NodeFeature` object per node with attributes such as
`accelerator`, `leaf`, `spine`, and `core`;
- one managed `NodeFeatureGroup` object per distinct topology value, such as
one group for each switch or accelerator domain.

For example:

```yaml
apiVersion: nfd.k8s-sigs.io/v1alpha1
kind: NodeFeature
metadata:
name: network-topology-worker-a
labels:
app.kubernetes.io/managed-by: nfd-network-topology-updater
nfd.node.kubernetes.io/node-name: worker-a
spec:
features:
attributes:
network.topology:
elements:
accelerator: nvl3
leaf: leaf-12
spine: spine-2
core: core-1
```

`nfd-master` can then evaluate generated `NodeFeatureGroup` objects and maintain
their matching node lists in status.

This proposal would benefit from adoption of
[kubernetes-sigs/node-feature-discovery#2548](https://github.com/kubernetes-sigs/node-feature-discovery/issues/2548),
the nested `NodeFeatureGroup` proposal. Network topology is hierarchical: every
non-leaf switch group would contain nodes from lower-tier child groups, and the
top switch group may contain all nodes in the cluster. Nested groups would let
the updater represent that hierarchy by reference instead of duplicating all
child node memberships into each parent group.

[Topograph](https://github.com/NVIDIA/topograph) is proposed as the initial code base for the updater because it
already discovers and maintains cluster network topology information.

**Why is this needed**:

Large AI, HPC, and distributed storage clusters often need network-aware
placement. Workloads may need to prefer nodes under the same leaf switch, avoid
crossing higher-level fabric tiers, or understand accelerator network domains.

Topograph already models this kind of topology and has a design for publishing
it through NFD resources. Bringing that model into NFD as an optional updater
would give NFD users a consistent way to discover and maintain network topology
without deploying a separate integration layer.

This proposal is separate from the existing `nfd-topology-updater`, which
publishes node-local `NodeResourceTopology` objects. The new updater would focus
on cluster network fabric topology and publish through `NodeFeature` and
`NodeFeatureGroup`.

Start by reviewing Topograph's existing topology publication design and the repository's nfd-topology-updater, then read the nested NodeFeatureGroup proposal in issue #2548. Determine how an optional nfd-network-topology-updater would discover fabric topology and publish managed NodeFeature and NodeFeatureGroup resources. Done means the component represents node and hierarchical topology data through those NFD resources without duplicating the existing node-local updater.

Written by the indexing model from the issue text.