feat(workflow): expose RAGFlow reranker in knowledge nodes

[whyiug]

Summary

RAGFlow retrieval already accepts ragflow_ext.rerank_id in the Knowledge service, but workflow knowledge nodes had no way to configure or forward it. This PR completes that caller path for the standard knowledge-base workflow node.

Call chain: parameter modal → workflow DSL nodeParam.rerankId → KnowledgeNode → KnowledgeClient → /knowledge/v1/chunk/query as ragflow_ext.rerank_id.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Refactoring

Related Issue

Advances #650. Builds on the Knowledge service API added in #1231.

Changes

• Show an optional rerank model ID only for Ragflow-RAG knowledge nodes, with Chinese and English guidance.
• Trim values before saving/sending, remove blank values, and cap the workflow field at 512 characters.
• Remove stale rerank configuration when a node switches to another RAG strategy.
• Forward ragflow_ext.rerank_id only when the runtime strategy is Ragflow-RAG and the value is non-empty.
• Keep legacy DSL and the default request payload unchanged when no reranker is configured.

No console backend or database change is needed because workflow nodeParam is stored and forwarded as JSON. This PR intentionally covers the workflow knowledge-base node only; the Agent knowledge tool has a separate call chain and is outside this PR.

Testing

• Existing tests pass
• New tests added
• Manual testing completed against a deployed RAGFlow instance

Executed locally:

• Workflow test suite: 298 passed
• Knowledge workflow regression tests: 9 passed
• Frontend unit suite on Node.js 20: 10 passed
• Frontend production build: passed
• Changed frontend files: Prettier and ESLint passed
• Changed Python files: Black, isort, and flake8 passed
• Workflow payload validated against the existing Knowledge service ChunkQueryReq contract

The repository-wide npm run type-check is not currently green on upstream main because of pre-existing diagnostics outside this change. The new rerank helper and parameter path were checked separately, and the production build passes.

Screenshots

Not included. The new field is conditional on selecting a RAGFlow knowledge base and is covered by the frontend persistence tests and production build.

Checklist

• Code follows project coding standards
• Self-review completed
• Documentation updated where needed (UI copy and i18n)
• No breaking changes

AI assistance disclosure

I used OpenAI Codex (GPT-5) to help trace the call chain and expand the regression tests. I reviewed the implementation, compatibility boundaries, and test results line by line, and I take responsibility for this contribution.

[FenjuFu]

Reviewed against #650. This resolves the core request — configurable rerank for RAGFlow knowledge nodes — cleanly:

• KnowledgeClient.payload() only adds ragflow_ext.rerank_id when rag_type == "Ragflow-RAG" and the trimmed value is non-empty, so the default request payload and legacy DSL are unchanged.
• The rerankId field is capped at 512 chars on both the KnowledgeNode model and the frontend, and stale rerank config is cleared when the node switches away from Ragflow-RAG.
• Frontend + backend tests are included and CI is green.

The scope note (workflow knowledge-base node only, Agent knowledge tool left for a follow-up) is reasonable and honest. Looks correct to me; merge decision is the maintainers’.

[whyiug]

Thanks for reviewing this against #650 and for confirming the compatibility boundaries. I’ll keep this PR focused on the workflow knowledge-base path as reviewed, and handle the Agent knowledge-tool path separately rather than expanding this diff. I’ll leave the current head unchanged; all checks remain green.