doc: Bluetooth: Mesh: Align wording for models instantiation req

According to https://github.com/zephyrproject-rtos/zephyr/pull/61886#issuecomment-1713302331
we need to use "must only" for models that spec states:
`If supported, ... shall be supported by the primary element and shall
not be supported by any secondary element`.

Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>

doc/connectivity/bluetooth/api/mesh/cfg_cli.rst

@@ -17,8 +17,8 @@ All configuration functions in the Configuration Client API have ``net_idx``
 and ``addr`` as their first parameters. These should be set to the network
 index and primary unicast address that the target node was provisioned with.
 
-The Configuration Client model is optional, but should be instantiated on the
-first element if it is present in the composition data.
+The Configuration Client model is optional, and it must only be instantiated on the
+primary element if present in the Composition Data.
 
 API reference
 *************

doc/connectivity/bluetooth/api/mesh/cfg_srv.rst

@@ -15,7 +15,7 @@ mesh node. It does not have an API of its own, but relies on a
    controlled through the :ref:`bluetooth_mesh_heartbeat` API.
 
 The Configuration Server model is mandatory on all Bluetooth mesh nodes, and
-should be instantiated in the first element.
+must only be instantiated on the primary element.
 
 API reference
 *************

doc/connectivity/bluetooth/api/mesh/health_cli.rst

@@ -12,9 +12,9 @@ used in this function call. The second parameter is the ``ctx`` or message
 context. Message context contains netkey index, appkey index and unicast
 address that the target node uses.
 
-The Health Client model is optional, and may be instantiated in any element.
-However, if a Health Client model is instantiated in an element other than the
-first, an instance must also be present in the first element.
+The Health Client model is optional, and may be instantiated on any element.
+However, if a Health Client model is instantiated on an element other than the
+primary, an instance must also be present on the primary element.
 
 See :ref:`bluetooth_mesh_health_faults` for a list of specification defined
 fault values.

doc/connectivity/bluetooth/api/mesh/health_srv.rst

@@ -7,6 +7,8 @@ The Health Server model provides attention callbacks and node diagnostics for
 :ref:`bluetooth_mesh_models_health_cli` models. It is primarily used to report
 faults in the mesh node and map the mesh nodes to their physical location.
 
+If present, the Health Server model must be instantiated on the primary element.
+
 Faults
 ******
 

doc/connectivity/bluetooth/api/mesh/od_cli.rst

@@ -13,6 +13,9 @@ how long a node will advertise Mesh Proxy Service with Private Network Identity
 The On-Demand Private Proxy Client model communicates with an On-Demand Private Proxy Server model
 using the device key of the node containing the target On-Demand Private Proxy Server model instance.
 
+If present, the On-Demand Private Proxy Client model must only be instantiated on the primary
+element.
+
 Configurations
 **************
 

doc/connectivity/bluetooth/api/mesh/od_srv.rst

@@ -17,7 +17,7 @@ The On-Demand Private Proxy Server does not have an API of its own, and relies o
 :ref:`bluetooth_mesh_od_cli` to control it. The On-Demand Private Proxy Server
 model only accepts messages encrypted with the node's device key.
 
-If present, the On-Demand Private Proxy Server model must be instantiated on the primary
+If present, the On-Demand Private Proxy Server model must only be instantiated on the primary
 element.
 
 API reference

doc/connectivity/bluetooth/api/mesh/op_agg_cli.rst

@@ -13,11 +13,11 @@ a sequence of access layer messages to nodes supporting the :ref:`bluetooth_mesh
 The Opcodes Aggregator Client model communicates with an Opcodes Aggregator Server model
 using the device key of the target node or the application keys configured by the Configuration Client.
 
-The Opcodes Aggregator Client model must only be instantiated on the primary
-element, and it is implicitly bound to the device key on initialization.
+If present, the Opcodes Aggregator Client model must only be instantiated on the primary element.
 
-The Opcodes Aggregator Client model should be bound to the same application keys that the client models,
-used to produce the sequence of messages, are bound to.
+The Opcodes Aggregator Client model is implicitly bound to the device key on initialization. It
+should be bound to the same application keys as the client models that are used to produce the sequence of
+messages.
 
 To be able to aggregate a message from a client model, it should support an asynchronous
 API, for example through callbacks.

doc/connectivity/bluetooth/api/mesh/op_agg_srv.rst

@@ -13,8 +13,7 @@ a sequence of access layer messages.
 The Opcodes Aggregator Server model accepts messages encrypted with the node's device key
 or the application keys.
 
-The Opcodes Aggregator Server model can only be instantiated on the
-node's primary element.
+If present, the Opcodes Aggregator Server model must only be instantiated on the primary element.
 
 The targeted server models should be bound to the same application key that is used
 to encrypt the sequence of access layer messages sent to the Opcodes Aggregator Server.

doc/connectivity/bluetooth/api/mesh/priv_beacon_cli.rst

@@ -25,8 +25,7 @@ All configuration functions in the Private Beacon Client API have ``net_idx``
 and ``addr`` as their first parameters. These should be set to the network
 index and the primary unicast address the target node was provisioned with.
 
-The Private Beacon Client model is optional, and can be instantiated on any
-element.
+If present, the Private Beacon Client model must only be instantiated on the primary element.
 
 API reference
 *************

doc/connectivity/bluetooth/api/mesh/priv_beacon_srv.rst

@@ -28,8 +28,7 @@ Server model through the :c:struct:`bt_mesh_priv_beacon_srv` instance passed to
 changes to this configuration in the settings subsystem, the initial values may
 be overwritten upon loading.
 
-The Private Beacon Server model is optional, and can only be instantiated in the
-node's primary element.
+If present, the Private Beacon Server model must only be instantiated on the primary element.
 
 API reference
 *************

doc/connectivity/bluetooth/api/mesh/rpr_srv.rst

@@ -15,8 +15,7 @@ The Remote Provisioning Server does not have an API of its own, but relies on a
 :ref:`bluetooth_mesh_models_rpr_cli` to control it. The Remote Provisioning Server
 model only accepts messages encrypted with the node's device key.
 
-If present, the Remote Provisioning Server model must be instantiated on the primary
-element.
+If present, the Remote Provisioning Server model must be instantiated on the primary element.
 
 Note that after refreshing the device key, node address or Composition Data through a Node Provisioning Protocol
 Interface (NPPI) procedure, the :c:member:`bt_mesh_prov.reprovisioned` callback is triggered. See section

doc/connectivity/bluetooth/api/mesh/srpl_cli.rst

@@ -13,8 +13,8 @@ replay protection list (SRPL) of a node that supports the :ref:`bluetooth_mesh_s
 The Solicitation PDU RPL Configuration Client model communicates with a Solicitation PDU RPL Configuration Server model
 using the application keys configured by the Configuration Client.
 
-If present, the Solicitation PDU RPL Configuration Client model must be instantiated on the primary
-element.
+If present, the Solicitation PDU RPL Configuration Client model must only be instantiated on the
+primary element.
 
 Configurations
 **************

doc/connectivity/bluetooth/api/mesh/srpl_srv.rst

@@ -14,8 +14,8 @@ successfully processed by a node, the SSRC field and SSEQ field of the message a
 The Solicitation PDU RPL Configuration Server does not have an API of its own, and relies on a :ref:`bluetooth_mesh_srpl_cli` to control it.
 The model only accepts messages encrypted with an application key as configured by the Configuration Client.
 
-If present, the Solicitation PDU RPL Configuration Server model must be instantiated on the primary
-element.
+If present, the Solicitation PDU RPL Configuration Server model must only be instantiated on the
+primary element.
 
 Configurations
 **************