fix(knowledge): restore the per-base document-cap error mapping from #1013

[Lesereingrape]

What

Re-applies the error-mapping fix that was merged as #1013 (4e09aeb9) and then dropped from develop by 5e34c8a0 ("Apply the remaining working-tree changes"). In _map_knowledge_error (src/octop/api/routers/knowledge_bases.py):

• the per-base document cap is matched by its own stable wording "support at most" instead of the literal "at most 100";
• the per-user knowledge-base cap is matched by "can own at most" instead of "at most" and "knowledge bases" — the document-cap message also contains "knowledge bases", which is what made the two collide;
• restores the two regression tests fix(knowledge): map per-base document cap to KNOWLEDGE_DOC_LIMIT #1013 shipped, including the one that drives the mapping from the real KnowledgeRepo wording so the coupling cannot rot silently again.

CHANGELOG.md is unchanged on purpose: the first bullet under ## [Unreleased] / ### 修复 on develop still describes exactly this fix, so the changelog and the code disagree right now. That is also why I read 5e34c8a0 as a working-tree carry-over rather than a deliberate rollback — #1139/#1140/#1141 restore its other victims the same way.

Why it matters to a user

KnowledgeRepo.create_document raises f"knowledge bases support at most {max_documents} documents", and max_documents has been configurable per base since 90b8ca25 (CreateBaseBody.max_documents, ge=0, le=10_000, default 100). So for any base whose cap is not exactly 100, uploading one document too many answers 409 KNOWLEDGE_BASE_LIMIT — "每个用户最多可创建 20 个知识库" — to a user who is complaining about documents. Only bases at the default cap report correctly.

Attribution

The fix is sxh313's (#1013); the commit keeps him as author and carries a restore of … 4e09aeb9, reverted by 5e34c8a0 note. My part was noticing the code/changelog mismatch, re-deriving the reachable path, and re-filing it with the measurement below.

Verification

Against origin/develop (2209cdc9). I cannot run make all on this machine (no make), so I ran the four underlying steps by hand.

Red — the two restored tests against develop's current source:

tests/unit/api/test_knowledge_bases.py::test_custom_document_cap_is_not_reported_as_base_cap FAILED
> assert <ErrorCode.KNOWLEDGE_BASE_LIMIT'> == <ErrorCode.KNOWLEDGE_DOC_LIMIT'>
1 failed, 1 passed, 25 deselected in 23.20s

(The second restored test passes on both sides — it is the guard that keeps the base cap wording mapping to KNOWLEDGE_BASE_LIMIT, which is why the first replacement cannot be made naively.)

Green — with the mapping restored:

tests/unit/api/test_knowledge_bases.py                 27 passed
ruff check            → All checks passed!
ruff format --check   → 2 files already formatted
mypy --strict src/octop → Success: no issues found in 517 source files

Two disclosures:

• I did not run the full tests/unit tree for this branch. Locally on a Chinese Windows box that tree is red for unrelated environment reasons (tests/unit/db/*, cp936 migration reads) — tracked by [bug] 中文 Windows(cp936) 上跑 tests/unit/db：22 处 read_text() 按平台编码读迁移 SQL，19 个用例报 UnicodeDecodeError #1070 / test(db): 迁移脚本统一按 UTF-8 读，中文 Windows(cp936) 本地跑测试不再红 19 个 (#1070) #1072, and it is red on develop for those and for the deps switch in chore(deps): switch runtime packages to octop-* 1.0.0 #1136, independently of this diff.
• The wrong-message claim is a code read of _map_knowledge_error + KnowledgeRepo.create_document plus the unit test above; I did not drive a real upload through a running gateway.

Overlap with #910

My open #910 also edits _map_knowledge_error — but a different branch of it (adding KNOWLEDGE_PATH_INVALID around line 246), and both PRs append their tests at the end of tests/unit/api/test_knowledge_bases.py. If #910 lands first I will rebase this one; if this lands first, #910's remaining conflict is one hunk at the end of that test file.

AI assistance

This was prepared with an AI coding agent (Qoder CLI) on my machine; the diff, the red/green measurements and this text are agent output.

• A human has reviewed this diff before merge.