fix(mcp): let five of the six shipped languages name a metric

Three resolvers turned a user-authored word into an internal code by
comparing it against a hand-typed English list. The app ships six
languages, so five of them resolved nothing: `Fer` and `Żelazo` came back
as `unknown_nutrient` while the settings card rendered exactly those
words, and `poids` and `sommeil` reached no series at all.

Stop transcribing. `nutrients.names.*` and `measurements.type*` already
label these concepts in every bundle, so the match index is derived from
`locales` instead — a seventh language works the day its bundle lands,
with no edit at any call site. The nutrient tool's English labels now come
out of `messages/en.json` too, so the wire wording cannot drift from the
screen.

The MCP contract is unchanged in shape and stays protocol-level English.
What moves is which words are understood: `unknown_nutrient` /
`unknown_metric` still mean "could not place this word", distinct from a
placed name answering `no_data`. Nothing turns absence into data.

Two findings the sweep did not predict:

- `Puls` resolved to pulse-wave velocity, because the English
  display-name pass matches substrings and "pulse-wave velocity" contains
  it. An exact name now beats a loose English fragment.
- French and Italian use one phrase for body fat and fat mass, and three
  bundles use one for fat-free mass and lean body mass. A word two
  metrics claim resolves to neither; answering kilograms to someone who
  asked for a percentage is worse than saying the word was not
  recognised. The known set is pinned so a new collision surfaces.

The medication needles are the exception: they are drug names, with no
bundle to derive from. They fold to a normalised INN stem rather than to
a language, so `Metformin`, `Metformine`, `Metformina` and `Metforminum`
are one entry, and `Semaglutyd` and `Atorwastatyna` cost nothing to add.
A guard asserts no two molecules collapse onto one stem. Iron is the one
class with no stem to fold to — it is named for the element — so its word
list is hand-tabulated and says so.

Every English resolution that worked before returns the same answer.

docs/api/mcp-capabilities.md

@@ -99,6 +99,35 @@ Every read tool is annotated read-only / non-destructive / idempotent /
 closed-world — the read-only guarantee is structural (only read tools are
 registered for a read session), and the annotation merely advertises it.
 
+### Naming a metric or a nutrient
+
+The tools that take a free-text name — `compare_metric`,
+`get_metric_baseline`, `detect_changepoints`, `get_nutrients` — accept the
+metric's or nutrient's own display name in **any language HealthLog ships**
+(de / en / es / fr / it / pl), alongside the internal code and the English
+aliases. `poids`, `Blutzucker`, `Fer` and `Żelazo` reach the same series as
+`weight`, `blood_glucose` and `iron`. Case, accents and punctuation are
+folded, so `magnésium` and `MAGNESIUM` are one word.
+
+The accepted names are read out of the app's own message bundles rather
+than listed in the resolver, so a language works as soon as its bundle
+ships. Two consequences worth relying on:
+
+- **The vocabulary is still closed.** A word in no bundle is a miss, not a
+  guess: `{ present: false, reason: "unknown_metric" }` or
+  `"unknown_nutrient"`. That reason is distinct from `"no_data"`, which
+  means the name WAS understood and the record honestly holds nothing.
+  Widening the accepted spellings moves words from the first answer to the
+  second; it never turns absence into data.
+- **An ambiguous word is refused, not resolved.** Where a language uses one
+  phrase for two different measurements — French and Italian call both body
+  fat and fat mass `masse grasse` / `massa grassa`, and French, Italian and
+  Polish use one phrase for fat-free mass and lean body mass — the word
+  resolves to neither. Name those in English, or by their metric key.
+
+Responses are unchanged: labels and units come back in protocol-level
+English whatever language the request used.
+
 ### Clinical signals
 
 The v1.25 clinical-signals set — **grip strength**, **pain (0–10 NRS)**,