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/milestones.py

@@ -140,8 +140,14 @@ async def delete_milestone(milestone_id: int) -> dict:
     # Read the title BEFORE the delete: afterwards the row is trashed and the
     # confirmation could only echo the number back. A deletion the operator
     # cannot recognise is one they cannot tell was the wrong one.
-    doomed = await milestones_svc.get_milestone(uid, milestone_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 milestones_svc.get_milestone(uid, milestone_id)
+        title = getattr(doomed, "title", "") if doomed else ""
+    except Exception:
+        title = ""
     batch = await trash_svc.delete(uid, "milestone", milestone_id)
     if batch is None:
         raise ValueError(f"milestone {milestone_id} not found")