fix(nav): drop dedicated EOI route + alerts sidebar entry, fix paginated-URL bug

Trimmed two surfaces that didn't earn their nav weight:

  - The /[port]/documents/eoi route added in the previous commit was
    redundant with the per-interest EOI status milestones already on
    the interest detail and the existing eoi_queue tab inside the
    Documents hub. Removed the route + the "EOI queue" sidebar entry.
  - The Alerts sidebar entry was promoting a mostly-empty page that
    duplicated the dashboard alert rail. Dropped the entry; the
    /[port]/alerts route stays accessible via the dashboard rail's
    "View all" link and the topbar bell, which is enough for the
    audit-trail use case.

While testing the EOI tab, found and fixed a real bug: usePaginatedQuery
was producing malformed URLs like `…?tab=eoi_queue&signatureOnly=true?page=1&limit=25`
(two `?` separators) when the endpoint string already carried query
params. The API rejected those with 400, so the EOI tab in the
documents hub was silently broken. The hook now uses `&` when the
endpoint already contains a `?`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/hooks/use-paginated-query.ts

@@ -125,10 +125,14 @@ export function usePaginatedQuery<T>({
 
   const fullQueryKey = [...queryKey, apiParams];
 
+  // Endpoints that already carry a query string (e.g. `/api/v1/documents?tab=eoi_queue`)
+  // need our pagination params merged with `&`, not a second `?`. Without this guard
+  // the URL becomes `…?tab=foo?page=1` and the API rejects it as 400.
+  const separator = endpoint.includes('?') ? '&' : '?';
+
   const { data, isLoading, isFetching } = useQuery<PaginatedResponse<T>>({
     queryKey: fullQueryKey,
-    queryFn: () =>
-      apiFetch<PaginatedResponse<T>>(`${endpoint}?${apiParams}`),
+    queryFn: () => apiFetch<PaginatedResponse<T>>(`${endpoint}${separator}${apiParams}`),
   });
 
   const pagination = data?.pagination