bug(action): Configure OCR step hardcodes llm.protocol to openai, breaking openai-responses protocol

### OpenCodeReview Version
v1.11.2 (and all versions since v1.10.0 / PR #1051)

### Operating System
Linux (x86_64)

### Installation Method
GitHub Action (composite action `action.yml`)

### LLM Provider
OpenAI (`openai-responses` / Responses API)

### Bug Description
In `action.yml`, the `Configure OCR` step added in PR #1051 unconditionally overwrites `llm.protocol` with `"openai"` whenever `llm_use_anthropic` is not set to true:

```bash
NORMALIZED_USE_ANTHROPIC="$(printf '%s' "$OCR_USE_ANTHROPIC" | tr '[:upper:]' '[:lower:]')"
case "$NORMALIZED_USE_ANTHROPIC" in
""|true|1|yes)
OCR_USE_ANTHROPIC="true"
OCR_LLM_PROTOCOL="anthropic"
;;
*)
OCR_USE_ANTHROPIC="false"
OCR_LLM_PROTOCOL="openai"
;;
esac
ocr config unset provider
...
ocr config set llm.protocol "$OCR_LLM_PROTOCOL"
```

This causes two major issues:
1. It unsets any configured provider and ignores `OCR_LLM_PROTOCOL` passed via workflow step `env:` (e.g. `OCR_LLM_PROTOCOL: openai-responses`).
2. When calling OpenAI with the Responses API format (e.g. `llm_extra_body: '{"reasoning":{"effort":"medium"}}'` or when using reasoning models with function tools), all requests are forced to `/v1/chat/completions` instead of `/v1/responses`, resulting in `400 Bad Request` from OpenAI API (`Unknown parameter: 'reasoning'` or `Function tools with reasoning_effort are not supported for model in /v1/chat/completions`).

Prior to PR #1051 (e.g. in `v1.9.10`), `Configure OCR` did not touch `llm.protocol` or unset the provider, allowing `OCR_LLM_PROTOCOL: openai-responses` to be passed via environment variables directly to the CLI.

### Steps to Reproduce
1. In a GitHub Actions workflow, invoke `alibaba/open-code-review` with `llm_url: https://api.openai.com/v1`, `llm_use_anthropic: "false"`, `env: OCR_LLM_PROTOCOL: openai-responses`, and `llm_extra_body: '{"reasoning":{"effort":"medium"}}'`.
2. Inspect the step log: `Configure OCR` executes `ocr config set llm.protocol openai`.
3. In `ocr review`, all API calls fail with `POST "https://api.openai.com/v1/chat/completions": 400 Bad Request {"message": "Unknown parameter: 'reasoning'."}`.

### Expected Behavior
`action.yml` should allow using the `openai-responses` protocol (and any custom protocol) either by:
1. Preserving `OCR_LLM_PROTOCOL` when set in the environment:
```bash
if [ -z "$OCR_LLM_PROTOCOL" ]; then
case "$NORMALIZED_USE_ANTHROPIC" in
""|true|1|yes) OCR_LLM_PROTOCOL="anthropic" ;;
*) OCR_LLM_PROTOCOL="openai" ;;
esac
fi
```
2. Or exposing a dedicated `llm_protocol` input in `action.yml`.

### Logs / Error Output
```
POST "https://api.openai.com/v1/chat/completions": 400 Bad Request {
"message": "Unknown parameter: 'reasoning'.",
"type": "invalid_request_error",
"param": "reasoning",
"code": "unknown_parameter"
}
```

Start in action.yml at the Configure OCR step and compare its behavior with v1.9.10 and PR #1051. Reproduce the workflow using OCR_LLM_PROTOCOL: openai-responses and verify that the configuration no longer overwrites a supplied protocol or provider; the existing default behavior should remain available when no protocol is supplied.

Written by the indexing model from the issue text.