fix: support both 'llm' and 'chat_llm' config keys; handle dict core_entities

[octo-patch]

Fixes #731

Problem

When creating a project using the 2wiki benchmark configs (e.g. kag_config_knowledge_unit.yaml), which define the LLM config under the llm top-level key, project.py was reading chat_llm — a different key used by other configs such as the medicine example. This caused the LLM config lookup to silently return an empty dict, leading to downstream errors (including AttributeError: 'TaggedScalar' object has no attribute 'openapi_types').

Additionally, the English-language knowledge unit prompt returns Core Entities as a dict ({"entity": "type", ...}), but knowledge_unit_extractor.py was always treating core_entities as a comma-separated string, causing a TypeError when the English prompt was used.

Solution

1. knext/command/sub_command/project.py — In both create_project and update_project, read the LLM config by checking llm first and falling back to chat_llm. This matches the existing logic in kag/common/config.py::get_default_chat_llm_config() and is backward-compatible with configs that use either key.

2. kag/builder/component/extractor/knowledge_unit_extractor.py — Handle core_entities as either a dict (English-language LLM output, where entity types are provided) or a comma-separated str (Chinese-language LLM output and triple-derived units). When it is a dict, the entity type value from the LLM is preserved instead of defaulting everything to "Others".

Testing

Verified the diff matches the fix described by the maintainer in the issue thread. The changes are backward-compatible: configs using chat_llm continue to work, and both Chinese and English prompt outputs for core_entities are correctly handled.