fix(knowledge): retry document processing after transient indexing failures

[yeliheng-010]

Description

When BatchIndex fails inside processChunks, the knowledge row is marked failed and the function returns nil. ProcessDocument therefore acks the document:process task, so its configured retries (MaxRetry(3)) never run. A short embedding-provider or vector-store outage that outlasts the indexer's in-process backoff (5 attempts, ~6 s) leaves the document permanently failed until someone reparses it by hand. For data-source documents the sync cursor has already moved past the item, so an unchanged incremental sync does not reprocess it either.

This change keeps the existing cleanup but defers the terminal status to the last attempt:

• While the task has attempts left (summaryTaskWillRetry, which already reads both asynq and Lite executor retry metadata), the partial chunks and vectors are still removed, the row stays processing, and the error is returned so the queue re-runs the idempotent parse.
• On the final attempt, or for callers without a retry loop, the row is marked failed exactly as before and nil is returned, so dead-letter handling is unchanged.
• The status write now logs its error instead of discarding it.

No schema, API, config or dependency changes.

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 💥 Breaking change
• 📚 Documentation update
• 🎨 Refactor
• ⚡ Performance improvement
• 🧪 Test
• 🔧 Configuration / Build / CI

Related Issue

No existing issue. Related but different scope: #3005 (closed, resumable embedding across vendor files), #2593 (sub-batch pacing/retry inside the embedding client), #1348 (cleanup context after timeout), #3656 (chunk cleanup on quota failure). None of them propagate the BatchIndex error to the task queue.

Testing

Regression tests (knowledge_process_index_retry_test.go):

• TestProcessChunksRetriesBatchIndexFailureBeforeLastAttempt fails on main (An error is expected but got nil) and passes with the fix.
• TestProcessChunksFailsKnowledgeOnLastBatchIndexAttempt checks the final attempt still records failed and cleans up.

Real backend run: native Lite server (SQLite + lite vector store, Lite task executor), real Ollama bge-m3 behind a local proxy that returns 503 for embedding requests while a fault flag is set, and an RSS data source served by a local HTTP feed. This exercises the shared ingest/queue path, not an external SaaS connector.

Scenario	main (bccb4b1)	This PR
Outage covers the first attempt only, then the dependency is restored	Row failed after the first attempt; 0 chunks / 0 vectors; no task retry; a later unchanged sync creates/updates nothing and the row stays failed	Row stays processing after the first attempt, the task retries automatically, ends completed with 1 chunk / 1 vector containing the source text; a later unchanged sync writes nothing
Outage never ends	—	Row ends failed with the 503 message after the retries (20 rejected embedding requests, ~46 s); no further requests after it settles

Checks:

• git diff --check origin/main...HEAD
• gofmt -l on changed files (clean)
• go vet ./internal/application/service
• go test -race -count=1 -run 'TestProcessChunks|TestSummaryTaskWillRetry' ./internal/application/service
• golangci-lint run --new-from-rev=origin/main ./internal/application/service/... (0 issues)
• go build -tags sqlite_fts5 ./cmd/server
• LOG_FORMAT= go test -count=1 ./internal/application/service ./internal/router on both main and this branch: the same 21 tests fail on both in this Windows environment (sandbox/symlink/data-source schedule tests); the failure sets are identical, no new failures. The full repository suite was not run; checks covered the changed package and the task router.

Not covered: the Redis/asynq worker path was not run end to end here (the Lite executor was); the retry decision uses the same asynq retry metadata as the existing summary retry path.

Prepared with AI assistance.

Checklist

• git diff --check origin/main...HEAD passes
• Changed source files are formatted
• Targeted tests for the changed packages/components pass
• Diff-scoped lint passes where applicable (for Go: golangci-lint run --new-from-rev=origin/main ./...)
• Full-repository checks were run, or any unrelated/environment-dependent failures are documented above
• Self-reviewed the code
• Added/updated tests covering the change
• Updated related documentation (README, website-docs/, Swagger annotations, etc.)
• Breaking changes are clearly called out in the description above