fix(auth-cursor): map reasoning effort and service tier onto Cursor model params

[nahwan-kim]

Problem

Cursor's model catalog names the reasoning knob differently per model. On one account today:

model	catalog parameter
claude-sonnet-5-5, claude-haiku-5-5	reasoning_effort
claude-opus-5-5, claude-fable-5-1	effort (opus also fast, fable also thinking)
kimi-k3	reasoning (low/high/max)

chatParams only produces reasoning_effort, and resolveModelSelection drops ids a model does not expose. So a client's reasoning effort was silently ignored for opus, fable and kimi, which always ran at their catalog default. There was also no way to request Opus fast mode.

Change

• resolveModelSelection offers the requested reasoning_effort to a model's effort or reasoning parameter when the model has no reasoning_effort. Allowed-value filtering is unchanged: a value the model does not list is still dropped.
• An effort of none sets thinking=false on models that expose thinking; any other effort sets thinking=true.
• service_tier: "priority" maps to fast=true, forwarded only where the model has a fast parameter. The host's Responses-to-chat translation drops service_tier, so buildGenerateRequest falls back to ExecutorRequest.OriginalRequest for /v1/responses callers.
• README: one sentence on the translations.

Testing

• gofmt -l clean, go vet ./... clean, c-shared build OK, go test -race ./... passes.
• New unit tests: effort to effort / reasoning, unlisted value dropped, none to thinking=false, fast forwarded or dropped by model, service_tier mapping, and the OriginalRequest fallback.
• Live check through CLIProxyAPI v8.0.8 /v1/responses on a real account (output tokens on a fixed math prompt, low vs max): opus 172 vs 630, fable 196 vs 516; before this change opus stayed at 205-263 for both. Opus with service_tier: "priority" streamed about 250 tok/s vs about 95 tok/s without it (3 runs each, same prompt).