[Docs] Explain model-specific reasoning capabilities

[roomote-roomote]

​Opened on behalf of @mrubens. View the task or mention @roomote-roomote for follow-up asks.

What changed

• Explain that reasoning levels are model-specific and can vary between provider routes for the same model family.
• Document how refreshed model metadata limits the picker and validates custom mapping presets against the selected model's supported levels.
• Clarify the metadata and verification limits for custom and self-hosted OpenAI-compatible endpoints.

Why this change was made

A recent user question highlighted that local and less-common models may support different reasoning-level subsets. Roomote already enforces those capabilities in the model picker and preset flow, but the public model guide did not explain that users should verify the per-model choices.

Impact

People configuring models can distinguish a provider or model capability limit from a Roomote failure, refresh stale metadata after provider changes, and avoid assuming that every model accepts every reasoning level.

[roomote-community]

1 issue outstanding. See task

• apps/docs/models.mdx:397-401 says endpoint-reported reasoning metadata hides the selector, but endpoint discovery does not collect that capability and unknown models keep it visible.

_{Reviewed 3d2fe6e}

[roomote-community]

Endpoint discovery does not report reasoning capabilities to Roomote: buildLocalProviderModel only retains context and pricing fields. An endpoint model that Roomote cannot otherwise identify has null metadata, and the settings UI deliberately leaves the selector visible for unknown support. Consequently, an endpoint that omits reasoning support will not hide the selector as this paragraph says. Describe this metadata as best-effort Roomote catalog data, or state that the selector is hidden only when its metadata explicitly reports no configurable reasoning.