Expand test coverage for Quarkus LangChain4j integration

## Description

At present we only have coverage for the langchain4j-agent extension + Quarkus LangChain4j. We should add additional modules to `integration-tests` for the other LangChain4j extensions.

For now, let's keep everything separate and **NOT** add anything new under `integration-test-groups`. Any new modules should be added to `integration-tests`. I propose to initially add the following (see details in sub-issues). If anyone has suggestions for other scenarios, feel free to create a sub-issue or modify the existing ones.

* langchain4j-chat-ql4j
* langchain4j-embeddings-ql4
* langchain4j-embeddingstore-ql4j

## Test guidelines

### LLM Mocking Strategy

We should be able to use WireMock to stub and record LLM interactions, using existing patterns from other langchain4j integration tests. See [here](https://github.com/apache/camel-quarkus/blob/main/integration-tests/langchain4j-agent/src/test/java/org/apache/camel/quarkus/component/langchain4j/agent/it/Langchain4jAgentTestResource.java) for an example.

### Implementing tests

These tests should reflect how a real user builds an application with both Camel Quarkus and Quarkus LangChain4j. The existing `langchain4j-agent-ql4j` test is **not** a good template — it copies source from the standalone agent test, which manually creates `OllamaChatModel` beans via CDI producers. A real user would let QL4J auto-produce model beans etc via `application.properties` and consume them from Camel routes. The new tests should follow the real-world pattern.

**Let QL4J own the model configuration.** Users add a QL4J model provider dependency (e.g., `quarkus-langchain4j-ollama`), configure it via `application.properties`, and QL4J auto-produces `ChatModel`, `EmbeddingModel`, etc. as CDI beans. Camel routes then consume those beans from the registry. The tests should validate this exact flow — not bypass it with manual bean producers.

### Dependencies

Use the QL4J BOM for version management. Depend on QL4J model provider extensions, not bare `dev.langchain4j` artifacts:

```xml

io.quarkiverse.langchain4j
quarkus-langchain4j-bom
${quarkiverse-langchain4j.version}
pom
import

io.quarkiverse.langchain4j
quarkus-langchain4j-ollama

org.apache.camel.quarkus
camel-quarkus-langchain4j-chat

io.quarkus
quarkus-rest


io.quarkus
quarkus-rest-jackson

```

### Application Configuration (application.properties)

Configure the model provider via QL4J properties — the same properties a real user would set. The WireMock test resource overrides the base URL at test time.

```properties
# QL4J model provider configuration (base-url overridden by WireMock test resource)
quarkus.langchain4j.ollama.base-url=http://localhost:${quarkus.http.test-port:8081}/v1
quarkus.langchain4j.ollama.api-key=test-key
quarkus.langchain4j.ollama.chat-model.model-name=gpt-4o-mini

# Deterministic responses make WireMock stub matching reliable
quarkus.langchain4j.ollama.chat-model.temperature=0.0

quarkus.langchain4j.ollama.log-requests=true
quarkus.langchain4j.ollama.log-responses=true

# Disable QL4J dev services — tests use WireMock, not a real Ollama container
quarkus.devservices.enabled=false
quarkus.langchain4j.devservices.preload=false

# Increase test timeout for LLM interactions
quarkus.http.test-timeout=120S
```

Start with the existing integration-tests/langchain4j-agent test and its Langchain4jAgentTestResource.java WireMock pattern. Add separate integration-tests modules for langchain4j-chat-ql4j, langchain4j-embeddings-ql4, and langchain4j-embeddingstore-ql4j, using QL4J-managed model configuration and WireMock rather than manual producers. Done means the scenarios exercise Camel routes with auto-produced CDI models and add nothing under integration-test-groups.

Written by the indexing model from the issue text.