fix(scribe): a delete must not depend on the lookup that names it (#3273)

CI caught the naming work reaching for Postgres from the unit lane, and the
connection error was the symptom of a real design fault rather than a test
gap: reading the title BEFORE the delete put a live query on the delete path,
so a lookup that failed would have stopped the delete happening.

That is a decoration breaking its payload — the same mistake just fixed in
rules_etag, made again two commits later. Every title lookup now fails open:
delete_task, delete_note, delete_milestone, delete_snippet and rule_history
lose the name, never the operation.

The five unit tests mock the lookup rather than reaching for a database, and
delete_note gains one asserting the delete still happens when the lookup
raises — the behaviour, not just the absence of a crash.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/scribe/mcp/tools/snippets.py

@@ -496,8 +496,14 @@ async def delete_snippet(snippet_id: int) -> dict:
     uid = current_user_id()
     # Read before deleting so the confirmation can NAME what went — an id
     # alone leaves the operator unable to tell which snippet this was.
-    doomed = await snippets_svc.get_snippet(uid, snippet_id)
-    title = getattr(doomed, "title", "") if doomed else ""
+    # Fail-open: the title is a COURTESY on top of the delete, so a lookup
+    # that errors must not stop the delete happening. Same posture the
+    # staleness marker takes — a decoration may never break its payload.
+    try:
+        doomed = await snippets_svc.get_snippet(uid, snippet_id)
+        title = getattr(doomed, "title", "") if doomed else ""
+    except Exception:
+        title = ""
     if not await snippets_svc.delete_snippet(uid, snippet_id):
         raise ValueError(f"snippet {snippet_id} not found")
     return {"deleted": True, "id": snippet_id, "title": title}