fix(knowledge): reject empty document extraction

[userInner]

Branch strategy

• Active development targets main.

What this PR does

Before this PR:

Knowledge items whose reader or chunker produced no indexable text were rebuilt with an empty material and marked as completed. Scanned or image-only PDFs therefore appeared ready even though their content and chunks were empty.

After this PR:

Indexing rejects zero-chunk extraction results before embedding or material replacement. The existing job settlement path records a clear failure reason, so the item is shown as failed and remains available for reindexing after OCR or document-processing settings are corrected.

Fixes #19095

Why we need it and why it was done in this way

The zero-chunk boundary is the first shared point at which every reader result has been normalized and proven unusable for both vector and lexical retrieval. Rejecting there prevents paid embedding calls and avoids replacing a material with an empty index while reusing the existing failed-status, tooltip, and reindex behavior.

The following tradeoffs were made:

An empty extraction is treated as a failed indexing attempt instead of a successful empty document. This makes the failure visible but requires users to correct the source or processing configuration before reindexing.

The following alternatives were considered:

• Keeping the completed status and relying on a log warning was rejected because users cannot distinguish an empty extraction from a searchable item in the UI.
• Adding automatic OCR fallback was not included because processor selection and OCR configuration are separate concerns and may involve external services or user costs.

Links to places where the discussion took place: #19095

Breaking changes

None.

If this PR introduces breaking changes, please describe the changes and the impact on users.

Special notes for your reviewer

Regression coverage includes readers returning no documents and whitespace-only documents. It also verifies that empty results never enter embedding or material replacement and that job settlement persists the actionable failure reason.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Branch: This PR targets main
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

Knowledge files that produce no indexable text now show a clear failed status instead of appearing ready with empty content and chunks.

[cherry-ai-bot]

Cherry Review · 通过

1 warning
逐条见行内评论。

[cherry-ai-bot]

建议修复：Authoritative Knowledge workflow documentation still describes zero-chunk indexing as successful completion, contradicting the changed handler's failure behavior.

inv_9f9316ad75d110ea#c0