fix: push mailing lists locally, fix upload menu, drop the events feed

Opening a mailing list from More → Projects still blanked. The cause was not in
handleTabNavigation: the row called openMailingList and then dismiss(), so a
path rebuild and a pop of this very view raced each other. Projects already
lives in the More tab, so there is nothing to navigate to — push
MailingListDetailView directly, which also lands back on the project rather than
on Mailing Lists. Sources and trackers keep routing, because they really do land
in other tabs.

The upload controls did nothing. Two .confirmationDialog modifiers on one view
leave one silently dead, and this view already had one for delete, so the tag
picker never presented. It is a Menu now, which also puts the tags one tap away
instead of two.

The ticket activity feed is removed. todo.sr.ht's root events resolver joins
event.participant_id, which references participant(id), against
participant.user_id — different id spaces — so it returns an empty list for
every user. The rows exist; that join cannot find them. Ticket.events is
unaffected because it filters on ticket_id, which is why ticket timelines work.
No client can fix this, and a screen that is permanently empty while blaming the
token's scopes is worse than no screen. Recorded in SCOPE.md with the query.

1 files changed, 15 insertions, 0 deletions

diff --git a/SCOPE.md b/SCOPE.md
index 008d084..407f292 100644
--- a/SCOPE.md
+++ b/SCOPE.md
@@ -8,6 +8,21 @@
 - Pronouns on profile (not in GraphQL schema)
 - Revoke personal access tokens (`@internal` in schema, inaccessible)
 - Archive a message to a list (`archiveMessage` is `@internal`, inaccessible)
+- Ticket activity feed (todo.sr.ht's root `events` query is broken upstream and
+  returns an empty list for every user). `event.participant_id` references
+  `participant(id)`, but the resolver joins it against `participant.user_id`:
+
+  ```sql
+  FROM event ev
+  JOIN participant p ON p.user_id = ev.participant_id   -- id space vs user id space
+  WHERE p.user_id = <viewer>
+  ```
+
+  The rows exist — the writer inserts `participant.ID` for the submitter and for
+  every subscriber — but that join cannot find them. `Ticket.events` is
+  unaffected because it filters on `ev.ticket_id`, which is why ticket timelines
+  work. Nothing a client can do fixes this; revisit only if sr.ht changes the
+  resolver.
 - Subscribe to a mailing list (`mailingListSubscribe` exists, but `MailingList`
   has no `subscription` field and sr.ht has no discovery API, so there is no way
   to find a list you are not already subscribed to — see hub.sr.ht above)