multi2vec_* factories accept vectorize_collection_name and silently drop it

Every multi2vec_* factory accepts vectorize_collection_name and then drops it.

The text factories forward it. The multimodal ones take the same argument and never use it.
Nothing is logged either, so vectorize_collection_name=False has no effect and the collection name is still folded
into the vectors.

Reproduced on 4.22.0 with no server, since these factories are pure config builders. Asking every
factory for vectorize_collection_name=False and reading the config it emits:

text2vec_cohere      vectorizeClassName=False     honoured=True
text2vec_openai      vectorizeClassName=False     honoured=True
multi2vec_cohere     vectorizeClassName=<absent>  honoured=False
multi2vec_clip       vectorizeClassName=<absent>  honoured=False
multi2vec_voyageai   vectorizeClassName=<absent>  honoured=False
multi2vec_jinaai     vectorizeClassName=<absent>  honoured=False

The key is absent rather than wrong, so the server applies its own default. The docstring on these
same methods says that default is True.

While confirming it I found something that probably decides which fix you want. None of the eight
_Multi2Vec*Config classes has a vectorizeClassName field at all. Both text config classes do. So
the factories are accepting an argument the config model below them has no slot to hold, which
reads less like a missed line and more like the parameter was copied into signatures where it was
never supported.

That leaves a question I cannot answer from the client, and it changes the fix:

• If Weaviate does support it for multimodal, the field needs adding to those config classes and
  passing through.
• If it does not, the parameter cannot ever work there, and the fix is to drop it from those
  signatures or raise on it.

Happy to write either patch once you say which.

A note on severity. Not a security hole. It is just quiet: someone turning it off
for a multimodal collection gets vectors they did not ask for, and nothing tells them.

What I did not check. multi2vec_google needs location and project_id to build, so it is
covered by reading the code and not by the run above. I also did not check the async client or the
non-named-vector Configure.Vectorizer paths, which look like they have the same shape.

Start with the multi2vec_* factory entry points and the eight _Multi2Vec*Config classes, then compare them with the text factory and config implementations that already carry vectorizeClassName. Confirm whether Weaviate supports this setting for multimodal configurations, including multi2vec_google, before choosing the fix. Done means the supported behavior is explicit and the argument is no longer silently ignored across the synchronous, async, and non-named-vector paths.