fix(llama-server): one name, since a second cannot win the id

#732 reversed the alias order on the theory that llama-server reports the last
entry as the `id`. It does not, and the endpoint still advertised
id="chat" after the rollout.

server-models.cpp keeps aliases in a std::set, so they are sorted and the first
becomes the id. "chat" sorts before "qwen3.6-35b-a3b" in either flag order, so
the descriptive name could never win while "chat" was configured.

Dropping it costs nothing, which the previous two attempts missed. A second name
would only earn its place as a stable handle for machine consumers, and there is
nothing to stabilise: a single-model server ignores the request's `model` field
entirely. Verified twice against the live endpoint — "voellig-erfundenes-modell-
xyz" and "irgendein-quatsch-123" both returned normal completions reporting
"model":"chat". No consumer config can break on a model swap, alias or not.

The e2e check is rewritten accordingly: asserting a substring appears in the
response cannot see which name holds the id, so it now asserts there is exactly
one name and no second one competing for it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubernetes/apps/llama-server/deployment.yaml

@@ -94,20 +94,20 @@ spec:
             # --hf-repo string, which is unreadable in a model picker and in
             # logs.
             #
-            # Order matters, and not the way it reads: llama-server reports the
-            # LAST entry as the model's `id` and lists the rest under `aliases`.
-            # So the descriptive name goes last to be the one a picker shows —
-            # it says which model is actually answering, which a bare "chat"
-            # hides and which matters as soon as a second chat model exists.
+            # Exactly one name, because a second one cannot be had usefully:
+            # llama-server keeps aliases in a sorted set and reports the first as
+            # the model's `id`, so with `chat` alongside this the picker always
+            # showed `chat` — in either flag order, since "chat" sorts first.
             #
-            # `chat` remains a stable handle for machine consumers — Home
-            # Assistant, Paperless, CI — whose config should survive the next
-            # model swap without an edit. Note that nothing routes on either
-            # name: a single-model server ignores the request's `model` field
-            # and answers to any string. These names exist to be advertised on
-            # /v1/models, which is what a client reads to build its picker.
+            # Dropping it costs nothing. A second name would only be worth
+            # having as a stable handle for machine consumers, and there is
+            # nothing to stabilise: a single-model server ignores the request's
+            # `model` field entirely and answers to any string, verified against
+            # this endpoint. So no consumer config can break on a model swap,
+            # with or without an alias. The name exists purely to be advertised
+            # on /v1/models, which is what a client reads to build its picker.
             - --alias
-            - chat,qwen3.6-35b-a3b
+            - qwen3.6-35b-a3b
             # Qwen3.6 enables thinking by default. At ~11.6 tok/s that spends
             # minutes reasoning before answering, and a request with a modest
             # max_tokens returns an empty `content` with finish_reason "length"

kubernetes/e2e-test.sh

@@ -614,13 +614,11 @@ check "chat completion stops rather than truncating" \
 check "chat answer is coherent (knows Paris)" \
     bash -c 'jq -re ".choices[0].message.content" /tmp/llm_body | grep -qi paris'
 
-# Both names must be advertised, because advertising is all that a single-model
-# server does with them: it ignores the request's `model` field entirely and
-# answers to any string, so posting a name and getting a reply proves nothing.
-# /v1/models is what a client reads to populate a picker, and it is the only
-# place the alias is observable.
-check "model list also offers the chat handle" \
-    http_body "https://llm.renner.uno/v1/models" '"chat"'
+# Only one name is configured. A second would be advertised alongside it and,
+# if it sorted first, would take the id — which is what a picker displays.
+check "no second name competes for the id" \
+    bash -c 'test "$(curl -sk --resolve "llm.renner.uno:443:$LB_IP" --max-time 15 \
+        "https://llm.renner.uno/v1/models" | jq -r ".data[0].aliases | length")" = "1"'
 
 # Reached from the monitoring namespace, which ai-ns.yaml admits; there is no
 # ingress for this Service by design.