`/api/show` returns no `capabilities` and empty `details` fields

Summary

The Ollama-compatible /api/show returns a details object whose fields are empty strings, and no capabilities key.

curl -s -X POST http://localhost:12434/api/show \
  -H "Content-Type: application/json" -d '{"model":"ai/functiongemma"}' | jq

{"details": {"format": "gguf", "family": "", "families": [""],
             "parameter_size": "", "quantization_level": ""}}

For reference, Ollama returns capabilities from this endpoint (e.g. ["completion","vision","tools","thinking"]), and clients commonly use it to decide whether to offer tool-using features for a given model.

The other surfaces do not carry this information either:

• GET /engines/v1/models returns {"id","object","created","owned_by","dmr"}
• docker model inspect ai/functiongemma returns config, created, id, tags

As a result, a client written against the Ollama-compatible API cannot determine what a model supports.

A second, smaller problem is that the details fields are empty strings rather than missing keys, so callers may read them as real values.

Suggested resolution

Populate capabilities and the details fields in /api/show, matching the Ollama-compatible contract.

Related: #1045. When tool support is missing at runtime, the response does not indicate it, so the absence cannot be detected after the fact either.

Environment

• Model Runner client v1.2.6, Docker Desktop engine 29.7.2
• Backend llama.cpp b9879-metal, macOS, Apple Silicon
• Model: ai/functiongemma

Start by tracing the /api/show entry point and its model metadata response, using the provided curl request with ai/functiongemma as a reproduction. Compare the response with the Ollama-compatible contract; done means capabilities and populated details fields are returned without treating empty values as real metadata.