fix(telemetry): record a pull on get_task, closing the surfaced→pulled loop

Closes #2245. note_usage_events recorded `surfaced` for every auto-inject menu
line regardless of kind, but `pulled` only from get_note, get_snippet and the
REST snippet route. get_task recorded nothing.

Auto-inject ranks kind-blind over a corpus that is overwhelmingly tasks and
issues, so tasks are most of what it surfaces. Measured live, "write a function
to debounce a callback in the frontend" returned three tasks and zero snippets —
all three written as surfaced, none able to record a pull.

surfaced and pulled only mean anything as a PAIR; the rate between them is what
#1038 and #2085 gate on. So the gap sat exactly where the volume is, and the
metric would have said "auto-inject surfaces things nobody opens" for its own
dominant kind — an artifact of the instrumentation, not a fact about the feature,
and one that pointed at a plausible-sounding wrong conclusion.

get_note already carried a comment stating this was meant to cover ANY note kind
precisely so tasks wouldn't look like dead weight. get_task is a separate tool in
a separate module and never got the call — sibling drift, invisible because a
missing side effect changes no return value.

Guarded by a rule-#33 contract test that asserts, by source inspection, that
every getter reachable from an auto-inject menu calls record_pulled. Source
inspection because no behavioural test can see a call that isn't there.

Not fixed here: the REST note/task detail routes still record nothing while the
REST snippet route records `rest_snippet`. That asymmetry is real, but a human
reading a note in a browser is arguably not the same event as an agent recalling
one, and collapsing them could skew the signal the other way. Raised as a
question for the retrieval survey instead of decided in passing.

Pre-fix rows under-count task pulls, one-sidedly by kind — treat them as unknown
rather than zero.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs

src/scribe/mcp/tools/tasks.py

@@ -27,6 +27,7 @@ from scribe.services import rulebooks as rulebooks_svc
 from scribe.services import systems as systems_svc
 from scribe.services import task_logs as task_logs_svc
 from scribe.services import trash as trash_svc
+from scribe.services.note_usage import record_pulled
 
 
 async def list_tasks(
@@ -99,6 +100,14 @@ async def get_task(task_id: int) -> dict:
         data["suppressed_rules"] = applicable.get("suppressed_rules", [])
         data["suppressed_topics"] = applicable.get("suppressed_topics", [])
     data.update(await access_svc.describe_provenance(uid, note))
+    # Same reasoning as get_note's record_pulled, and this is the tool where it
+    # matters MOST: auto-inject ranks kind-blind over a corpus that is
+    # overwhelmingly tasks and issues, so tasks dominate what it surfaces. Without
+    # this the surfaced→pulled loop was open exactly where the volume is — every
+    # surfaced task counted as never-pulled because the tool that opens one didn't
+    # say so, driving auto-inject's measured pull-through toward zero for its own
+    # dominant kind. #1038 and #2085 are explicitly gated on that number (#2245).
+    record_pulled(user_id=uid, note_id=int(note.id), source="mcp_get_task")
     return data