Allow a suffix on team broker client IDs so clients that generate their own client ID can connect

### Description

The team broker currently requires the MQTT Client ID to be an exact string match for the username. In `forge/comms/v2AuthRoutes.js`:

```js
const parts = username.split('@')
teamId = parts[1]
if (username === clientId) {
authorized = await app.db.controllers.TeamBrokerClient.authenticateCredentials(username, password)
}
```

This is documented behaviour: "Please note that username **must** also be used for the client id to connect to the team broker", and "each username/password can only be used with a single MQTT client at a time."

**The problem**

A number of MQTT client libraries and low-code connectors do not give the user full control over the client ID. They accept a client ID and then append their own uniqueness suffix before connecting. Any such client cannot connect to the team broker at all, and there is no setting to relax the check. The behaviour is identical on FlowFuse Cloud and self-hosted, so there is no workaround available to a self-hosted customer either.

We have hit this with a partner who is building a Mendix based MES on top of a self-hosted FlowFuse for their end customer. Mendix's MQTT connector supports username, password and client ID, but always appends to the client ID to make it unique. They cannot use our broker as a result, and it is currently blocking their delivery.

**Suggested change**

Accept a client ID that is the username plus a suffix, in addition to an exact match. We already do exactly this for our own high availability instances, in `authenticateNrMqttNodeUser` in `forge/db/controllers/TeamBrokerClient.js`:

```js
if (parsedClientId.haId) {
clientIdValid = `${authId}:${parsedClientId.haId}` === clientId
} else {
clientIdValid = authId === clientId
}
```

So the shape of a suffix-tolerant client ID already exists in the codebase for one class of client. This request is to extend something equivalent to team broker clients.

**The design question this raises**

The exact match is not arbitrary. The comment immediately below it says "this test is to ensure that only a fixed number of clients can connect", so it is how we hold one credential to one connection and keep the licensed MQTT client count meaningful.

Relaxing the match to allow any suffix would let a single username open several simultaneous connections, which weakens that. If we want this, the concurrency limit probably needs to move from "client ID equals username" to counting or capping active connections per username at the broker. That is the part that needs a decision rather than an implementation.

**Acceptance criteria**

1. A client authenticating as `alice@32E4NEO5pY` with a client ID of `alice@32E4NEO5pY` followed by a suffix connects successfully.
2. The per-team MQTT client limit is still enforced, and a single credential still cannot be used to open unlimited concurrent connections.
3. Existing clients that send an exactly matching client ID continue to work unchanged.
4. The team broker documentation is updated to describe what is now accepted.

### Which customers would this be available to

Team + Enterprise Tiers (EE)

This should match wherever the team broker itself is already available, rather than introducing a different boundary.

### Have you provided an initial effort estimate for this issue?

I can not provide an initial effort estimate

Start with the client-ID check in forge/comms/v2AuthRoutes.js and compare it with authenticateNrMqttNodeUser in forge/db/controllers/TeamBrokerClient.js. Trace how active team broker connections and per-team client limits are enforced before deciding how suffixes should interact with credentials. Done means exact IDs still work, approved suffixed IDs connect, concurrency remains capped, and the team broker documentation reflects the final behavior.

Written by the indexing model from the issue text.