Agree VSS branch to VDM type mapping

I raised this topic in the VDM meeting a couple of weeks ago and @cpodalak requested I raise an issue. I noticed it as a result of work trying to generate DB schema definitions of VDM types.

## Summary
### Automated VSS translation to VDM
The current (initial) VSS to VDM translation tooling maps each VSS branch and the _properties_ (leaf nodes) within it in VDM to a GraphQL SDL object _type_ populated with _fields_ taken from the VSS leaf nodes. For example the VSS root branch _Vehicle_ becomes the VDM object type [_Vehicle_](https://github.com/COVESA/vdm/blob/bf155cdd60a519e8e62fca516dbd8366f3e92439/spec/vss/2025-09-17/modular/modular_spec/domain/Vehicle.graphql#L5) and its VSS leaf node _Vehicle.Speed_ in VDM becomes the field _speed_ in the type _Vehicle_.

### The potential problem
In VSS, vspec does not imply how leaf nodes are instantiated. It is not uncommon for nodes to be treated as key value pairs in data streams.

As stated the VDM tooling translates VSS branch nodes to a GraphQL SDL type. It would be common software engineering practice to instantiate the type as a complete structure, e.g. in a DB schema to instantiate the group of properties as a table. _This causes an implementation issue as VSS mixes up different categories of data, with different attributes, from related but different domains within branches._ For example, the VSS branch _Vehicle_ contains both dimensional nodes such as Vehicle.Height whose values change infrequently and nodes such as Vehicle.Speed where the data changes very frequently. An implementation that needs Vehicle.Speed recorded at 1Hz or quicker would be extremely wasteful storing, processing and transmitting Vehicle.Height at the same rate.

_This raises the question of whether the logical VDM types generated from VSS contain the right groups of fields for the domain being modeled? Are the types fit for purpose or is further decomposition needed?_

In the interests of clarity, it is not suggested a wholesale reworking of the VSS domains is being called for. That would be something that would be done over time as domains evolve and needs change.

## Further detail
It is true that APIs can selectively provide access only to the VDM fields that are needed, a GraphQL Query would be one example. It is also true that GraphQL SDL provides some mechanisms that could be used to select fields when generating schemas. These would provide one way to workaround the problems of 'fat' types like _Vehicle_.

That said, data-centric architectures treat data as a first class citizen and VDM is intended to provide greater ability to relate parts of the different models. One attribute of the VDM project is the opportunity to review what is good and what could be improved in VSS. This is similar to the domain review that took place when the capabilities project looked at the domain seat.

For example, whilst retaining the existing semantics for the particular properties, we might consider reworking groupings of properties in the types. In the example above dimensional vehicle data and quickly updating positional data in the Vehicle branch/type might become their own types, which the Vehicle type can reference. It would be sensible to consider whether that is something that can be applied consistently across the domains. Doing so would improve usability and coherence.