Fix LlamaIndexHook docs to stop claiming Ollama/vLLM support

[Lee-W]

The class docstring, the host field description, and the UI placeholder said host= could point LlamaIndexHook at Ollama or vLLM. get_llm() and get_embedding_model() return LlamaIndex's OpenAI / OpenAIEmbedding classes, which validate model= client-side against LlamaIndex's OpenAI-only model-name allowlists before any request is sent, so an Ollama/vLLM model name is rejected regardless of host. Document the real constraint and why it exists instead of the non-existent Ollama/vLLM support.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: [Tool Name] following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[uros-b]

+1, LGTM!

[ColtenOuO]

Thanks! LGTM overall

Should we also update provider.yaml in this PR?

The connection UI and the provider registry both read from provider.yaml, so the claim this PR is removing is still visible to users.

Two places in the llamaindex connection-types entry still carry it:

  - hook-class-name: airflow.providers.common.ai.hooks.llamaindex.LlamaIndexHook
    hook-name: "LlamaIndex"
    connection-type: llamaindex
    external-services:
      - OpenAI
      - Ollama          # <--
      - vLLM            # <-- 
    ui-field-behaviour:
      ...
      placeholders:
        host: "https://api.openai.com/v1 (optional, for custom endpoints / Ollama)"   # <--

I think we should also remove that and re-generate the get_provider_info.py

WDYT

[ColtenOuO]

Azure OpenAI addresses models by custom deployment names rather than OpenAI's canonical model names, so it doesn't really fit the "accepts OpenAI's exact model names" rule here.

Maybe just drop the Azure example and keep the internal gateway one?

[ColtenOuO]

ditto