Update LLM frontend docs to cover unconfigured status

[jtheory]

Our readme here doesn't yet cover how to handle the different LLM app config options, including the new "unconfigured" status added in #350 .

The general UX approach we'd like to model is:

• activate LLM features if they're enabled (either Grafana-provided or other config)
• hide LLM features from the user if they are disabled / opted-out
• prompt the user that an admin can opt in to LLM-powered features in the LLM plugin if status is unconfigured.

Once our readme has a trivial example, I can start nudging different squads to use this approach (plus get some UX input on how they should do it).

[sd2k]

Some example responses that may be useful here:

Plugin disabled:

{
  "message": "Plugin not found"
}

Plugin enabled but not configured:

{
  "details": {
    "openAI": {
      "configured": false,
      "error": "No functioning models are available",
      "models": {
        "base": {
          "error": "OpenAI not configured",
          "ok": false
        },
        "large": {
          "error": "OpenAI not configured",
          "ok": false
        }
      },
      "ok": false
    },
    "vector": {
      "enabled": false,
      "ok": false
    },
    "version": "0.10.4"
  },
  "message": "",
  "status": "OK"
}

Plugin enabled but "Disable all LLM features in Grafana" chosen (i.e. opted-out):

{
  "details": {
    "openAI": {
      "configured": true,
      "error": "LLM functionality is disabled",
      "models": null,
      "ok": false
    },
    "vector": {
      "enabled": false,
      "ok": false
    },
    "version": "0.10.4"
  },
  "message": "",
  "status": "OK"
}

---

The @grafana/llm has two relevant functions:

• health, which more or less returns the openAI object in the above response
• enabled, which I think most people are using, which calls health and checks that configured and ok are both true.

It sounds like we want to encourage people to use health and use the value of configured to prompt the user to opt-in?