add observability span around list_notifications
Wrap the bsky get_notifications call in a logfire span that captures
the raw response — total_count, unread_count, and per-unread-item
structured data (uri, cid, author handle, reason, reason_subject,
indexed_at, is_read). This makes "what did bsky actually return"
answerable from the trace instead of inferable from downstream code.
Motivation: hit a debugging wall trying to figure out why phi only
saw 1 of 3 valid mention notifications in a poll cycle. The existing
spans only showed phi's interpretation of the response (post-filter
batch size), not the raw bsky output. Without raw response capture
we can't distinguish "bsky returned only 1" from "bsky returned 3
but the filter dropped 2" from "bsky returned 3 with one already-read."
Only emits the unread_items attribute when unread > 0, so normal
quiet polls don't bloat the trace with empty arrays. Doesn't capture
read notifications since they're not the load-bearing part for this
question.