Two backend fixes for the v0.7.0 regression where a deleted document keeps
showing in the list ('delete success' toast) and a follow-up reparse then
reports the file is missing:
1. List filtering: applyKnowledgeListFilter now hides rows in the transient
'deleting' state from the default document list. The async delete pipeline
marks a row 'deleting' before tearing down its resources, so without this
the entry lingers as a normal doc until it is physically gone. Rows whose
delete task exhausts retries are flipped to 'failed' by the dead-letter
callback and stay visible so the failure remains actionable; an explicit
parse_status=deleting filter can still surface in-flight rows.
2. Delete ordering: DeleteKnowledge / DeleteKnowledgeList now delete the DB
row FIRST and defer physical file (+ extracted image) cleanup until after
the row is gone. Previously file removal ran concurrently with the
index/chunk/graph cleanup; when one of those failed the row was kept but
the file could already be deleted, producing a 'file missing but row
present' zombie that could neither be reparsed nor cleanly re-deleted.
Orphaning a file after the row is gone is the tolerable failure mode.
Adds a repository regression test covering the default/explicit deleting
visibility rules.
wizardchen
b9b81a6c3c