feat(smart-list): edit an existing list and pick privacy

[vladjerca]

Two gaps on the create and manage path, grouped because both touch
SmartListCreator.svelte and the same request layer.

Editing

There is no update path client-side. lib/requests/queries/users/ has
createSmartListRequest.ts and deleteSmartListRequest.ts and nothing else, so renaming a list
or retuning its filters means deleting it and building it again from scratch. The list loses its
slug in the process, which breaks any shared link to it.

This gets worse with every slice in this epic: the more filter dimensions a list can carry, the
more painful recreating one becomes.

• Add updateSmartListRequest.ts against the API's update endpoint, following the shape of the
  existing create request.
• Add a useUpdateSmartList hook next to useCreateSmartList, invalidating the same query keys.
  A new InvalidateAction.SmartList.Updated token is likely needed alongside Created and
  Deleted.
• Reuse SmartListCreator for the edit case rather than forking a second form. It needs to
  hydrate from an existing SmartList (name, source, media type, filters, privacy) instead of
  starting empty. SmartListFilterPreserver may already do part of the hydration work.
• Add an edit entry point to SmartListActions.svelte, which currently only offers delete and
  share.
• Route: an edit page alongside routes/lists/smart/create/.

Privacy

The API accepts public, private, or friends, and the client reads privacy back on
SmartListSchema, but the create form never sets it. Every list web creates gets the API
default, and there is no way to change it afterwards.

• Add a privacy selector to the create form and the edit form.
• Reuse whatever control personal lists already use for privacy so the two list types do not
  present the same choice differently.

Verification

Create a list, edit its name and filters, confirm the slug survives, confirm a shared link still
resolves, and confirm the privacy change takes effect on both the owner view and a signed-out
view.

Depends on the @trakt/api bump only insofar as the new filter keys should round-trip through
the edit form; the edit and privacy work itself is not blocked.