docs(swagger): add user_id query param to notifications endpoints (#837)

## Summary

- Declare an optional `user_id` query parameter on `GET
/notifications/{user_id}` and `GET
/notifications/{user_id}/playlist_updates` so SDK consumers can send the
requester id alongside the notifications-owner path id.
- Spec-only change; the global `resolveMyIdMiddleware` already reads
`c.Query("user_id")` and feeds it to `getMyId(c)`, so no backend code
needs to change.

## Why

The notifications handler personalizes the embedded `related.users`
field via `MyID: app.getMyId(c)` in `api/v1_notifications.go:336`.
`getMyId` reads from the **query string** `?user_id=`, not from the
path. Today the SDK only puts the user id in the path
(`/notifications/{user_id}`), so `MyID` resolves to `0`. The
`does_current_user_follow` SQL short-circuits to `false` (`WHERE $1 > 0
AND follower_user_id = $1` in `api/dbv1/get_users.sql.go`), and every
embedded user returns with `does_current_user_follow: false`.

Clients that prime these into a shared user cache (the web/mobile
tan-query layer does this in `primeRelatedData`) end up showing the
current user as not-following accounts they actually follow — until they
navigate to that user's profile directly and a personalized fetch
overwrites the cache entry.

A backend-only fix (`MyID: app.getUserId(c)`) would collapse two
semantically different ids: the notifications owner (path) and the
requester (current user). They are intentionally separable, since a
manager can read a managed user's notifications and should still see
relationships from their own perspective. Carrying the requester id
explicitly via the query keeps the two distinct.

## Notes for SDK regen

- The path param and the new query param share the name `user_id`.
OpenAPI 3 permits same-name params in different `in` locations, but
`openapi-generator-cli` (typescript-fetch, v6.0.0) may emit a duplicate
`userId` field in `GetNotificationsRequest`. If regen fails or produces
an ambiguous type, options: rename the path placeholder to `id`
(concrete URL unchanged; breaking change for `@audius/sdk` consumers) or
use `x-codegen-param-name` to disambiguate without altering the wire
format.
- Existing clients that don't pass the query param continue to work (the
new param is optional). They keep the same buggy behavior they have
today until the SDK is updated and call sites pass the requester id.

## Test plan

- [ ] Spec validates (`swagger-cli validate` / equivalent in CI).
- [ ] After SDK regen + client update: confirm
`does_current_user_follow` returns true for users the current user
actually follows in `related.users` on a fresh app boot (no profile
navigation required).
- [ ] Verify manager case: when a manager fetches a managed user's
notifications, the manager's `user_id` in the query produces
personalization from the manager's perspective.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

Author: raymondjacobson

api/swagger/swagger-v1.yaml

@@ -8194,6 +8194,15 @@ paths:
           required: true
           schema:
             type: string
+        - name: user_id
+          in: query
+          description:
+            The user ID of the user making the request. Required for
+            personalization of related users (e.g. does_current_user_follow)
+            in the response, and may differ from the path user_id when a
+            manager is reading a managed user's notifications.
+          schema:
+            type: string
         - name: timestamp
           in: query
           description: The timestamp from which to paginate
@@ -8287,6 +8296,15 @@ paths:
           required: true
           schema:
             type: string
+        - name: user_id
+          in: query
+          description:
+            The user ID of the user making the request. Required for
+            personalization of related users (e.g. does_current_user_follow)
+            in the response, and may differ from the path user_id when a
+            manager is reading a managed user's playlist updates.
+          schema:
+            type: string
       responses:
         "200":
           description: Success