v6: tenant updates are not split at the server's 100-tenant limit, so activate/deactivate fails above 100

Summary

WeaviateTenantsClient.update(List<Tenant>) sends every tenant it is given in one
PUT /v1/schema/{class}/tenants. Weaviate caps that request at 100 tenants, so any
update of more than 100 fails:

HTTP 422: PUT /v1/schema/MyCollection/tenants: maximum number of tenants allowed to be
updated simultaneously is 100. Please reduce the number of tenants in your request and
try again

activate(...) and deactivate(...) are affected too, since both delegate to update.

The Python and TypeScript clients both split this request at 100 internally, so the same
code written against either of them works and the Java one does not. That difference is
also a trap for anyone measuring the limit: probing with the Python client reports "4000 in
one request, no cap", because it is quietly measuring the client's own batching rather than
the server's behaviour.

Reproduction

var tenants = client.collections.use("MyCollection").tenants;

List<String> names = IntStream.rangeClosed(1, 101)
    .mapToObj(i -> "tenant-" + i)
    .toList();

tenants.create(names.stream().map(Tenant::active).toList());  // fine: creates are not capped
tenants.deactivate(names);                                    // HTTP 422

tenants.deactivate(names.subList(0, 100)) succeeds, which isolates the boundary.

Confirmed against Weaviate 1.39.0 at the REST layer as well, independently of the client:

PUT /v1/schema/{class}/tenants with 100 tenants -> 200
PUT /v1/schema/{class}/tenants with 101 tenants -> 422

Where the limit comes from

usecases/schema/tenant.go:

const ErrMsgMaxAllowedTenants = "maximum number of tenants allowed to be updated simultaneously is 100. ..."

func validateTenants(tenants []*models.Tenant, allowOverHundred bool) (validated []*models.Tenant, err error) {
	if !allowOverHundred && len(tenants) > 100 {
		err = uco.NewErrInvalidUserInput(ErrMsgMaxAllowedTenants)
		return validated, err
	}

AddTenants calls this with allowOverHundred=true and UpdateTenants with false, so
creating tenants is uncapped and only updating is limited. Any fix should keep that
asymmetry rather than chunking both.

What the other clients do

Python (weaviate/collections/tenants/executor.py, client 4.23.0):

UPDATE_TENANT_BATCH_SIZE = 100
...
batches = ceil(len(tenants) / UPDATE_TENANT_BATCH_SIZE)

TypeScript (src/collections/serialize/index.ts, client 3.14.0):

public static tenants<T, M>(tenants: T[], mapper: (tenant: T) => M): M[][] {
  const mapped = [];
  const batches = Math.ceil(tenants.length / 100);
  for (let i = 0; i < batches; i++) {
    const batch = tenants.slice(i * 100, (i + 1) * 100);
    mapped.push(batch.map(mapper));
  }
  return mapped;
}

In both, the split is applied on the update path only, and create passes the whole list
through — matching the server.

Where it is in the Java client

io/weaviate/client6/v1/api/collections/tenants/WeaviateTenantsClient.java (6.3.1):

public void update(List<Tenant> tenants) throws IOException {
  this.restTransport.performRequest(new UpdateTenantsRequest(tenants), UpdateTenantsRequest.endpoint(collection));
}

public void activate(List<String> tenants) throws IOException {
  update(tenants.stream().map(Tenant::active).toList());
}

public void deactivate(List<String> tenants) throws IOException {
  update(tenants.stream().map(Tenant::inactive).toList());
}

One performRequest for the whole list, and no chunking anywhere in the package.

Suggested fix

Split in update(List<Tenant>) at 100, so activate, deactivate and update are all
covered by the one change. Leave create alone.

Worth deciding explicitly what a partial failure means: with more than one request, a batch
can now fail after earlier batches have already been applied. Python and TypeScript both
leave the earlier batches applied and propagate the error.

Start in io/weaviate/client6/v1/api/collections/tenants/WeaviateTenantsClient.java, especially update(List) and its activate/deactivate callers. Check the existing tenant client tests and verify that updates over 100 are sent as batches while create remains uncapped; confirm errors are propagated consistently if a later batch fails.