fix(knowledge): delete the document directory even before it is indexed

[gloryfromca]

Summary

DELETE /api/v2/knowledge/documents/{doc_id} resolved the document directory through its SQLite row. The cascade writes that row a second or more after POST /documents has returned, so a delete that followed a create closely (an undo, a client retry) found no row, removed nothing, answered 204 — and the markdown left on disk was indexed right back in: the "deleted" document reappeared in GET /documents a few seconds later.

Markdown is the source of truth, so when the index has no row the directory is located on disk instead: its name ends in the doc_id (knowledge_writer.py: dir_name = f"{title_slug}_{root.doc_id}"), so a */*_<doc_id> glob under the scope's knowledge dir finds it. Response semantics are unchanged (204 when no indexed topics were removed, as documented).

Area

• architecture / correctness (knowledge subsystem)

Verification

• Reproduced on a live Tier-3 server before the fix: POST /documents (201) → DELETE 3 ms later (204) → GET /documents lists the document again, GET /documents/{id} → 200, directory still on disk (.work_context/agent_sim/logs/trace.jsonl, local).
• New unit test test_delete_document_removes_dir_before_the_index_has_the_row (real tmp root, repo mocked to return no row) — red without the disk lookup (assert not doc_dir.exists() fails), green with it. The existing idempotent test now pins EVEROS_ROOT to a tmp dir so it never touches ~/.everos.
• tests/unit/test_service/test_knowledge_crud.py + test_knowledge_api.py: 57 passed. make lint green.

Checklist

• tests added
• lint green
• no API contract change

Notes for Reviewers

_find_doc_dir runs in a worker thread (anyio.to_thread.run_sync), same as the existing rmtree. The glob is bounded to <knowledge_dir>/<category>/ — two levels, no recursion.

🤖 Generated with Claude Code

[gloryfromca]

Live before/after on the same repro (create → DELETE 3 ms later → wait 15 s → look):

	DELETE	GET /documents/{id} after 15 s	listed	directory on disk
before (main worktree, run 2 of the agent-sim driver)	204	200	yes	yes — resurrected
after (this branch, fresh root, port 8124)	204	404	no	no — GONE

Script: .work_context/agent_sim/repro_delete_before_index.py (local).

[gloryfromca]

Adversarial review round (subagent, read-only) found two should-fix items; both addressed in the follow-up commit:

1. doc_id reached the glob unvalidated. delete_document is exported from everos.service; only the HTTP route validates the id's shape, and delete_document("*", …) removed the first document of the first category. The directory name is now compared literally (name.endswith(f"_{doc_id}")), every match is removed.
2. 204 for a real deletion. The no-row branch reported a hard-coded deleted_topics=0, so a delete that beat the index answered 204 — indistinguishable from "never existed" and at odds with docs/knowledge.md. It now counts the topic files on disk (N_*.md, markdown is the truth) and answers 200 with that count; 204 remains for "nothing existed".

Test hardening: the fixture plants a sibling document and .taxonomy.md and asserts they survive (an rmtree(knowledge_dir) implementation passed the old test, fails this one), plus a parametrised case for an absent id, * and */_original. 60 tests green, lint green.