Read a playlist back before writing over it

Ten review findings in the remote-playlist work, all of them the same
shape: something acted on what it remembered instead of what the server
says now.

- A confirmed-gone playlist is forgotten whole — snapshot, list entry,
  and both ordering fences — so a refresh that started before the delete
  can no longer republish it, and a list refetch that fails offline no
  longer leaves it on screen.
- `.accountsDidChange` discards account-scoped content when the account
  it belonged to is no longer the effective one, as the status
  notification already did.
- A tab that stops being offered no longer stays selected: the browse
  view moves to the first available one, which reloads by itself.
- A Handoff account id is accepted only when that account is on the
  instance the playlist lives on.
- Composite writes moved up into `AccountService`, over a transport whose
  every method is exactly one request: create-with-privacy, rename, and
  set-description. The credential is rechecked between each pair, so a
  sign-out between the two halves of a create or an edit can no longer
  send the second half under the previous user's secret.
- Editing a playlist no longer forces it private. Invidious serialises
  visibility as `isListed` — `privacy.public?`, so unlisted and private
  are indistinguishable — which the snapshot now carries; the picker
  starts there, and sends nothing at all unless it was moved. Invidious
  keeps the stored visibility when the PATCH omits it (measured), so an
  untouched picker leaves it exactly as it was.
- Tapping Edit on a server-side playlist awaits an authenticated refetch
  first and populates the form from it; a failed refetch shows an error
  and no sheet.
- Playlist rows are keyed by row rather than by video id, which two rows
  of the same video share.
- The add-to-playlist sheet offers only accounts whose instance is
  enabled and that hold a credential, alongside the write capability.

Yattee/Services/API/InvidiousAPI.swift

@@ -208,6 +208,7 @@ actor InvidiousAPI: InstanceAPI {
             author: firstResponse.author,
             authorId: firstResponse.authorId,
             videoCount: firstResponse.videoCount,
+            isListed: firstResponse.isListed,
             videos: allVideos
         ).toPlaylist(baseURL: instance.url)
     }
@@ -320,6 +321,7 @@ actor InvidiousAPI: InstanceAPI {
             author: firstPage.author,
             authorId: firstPage.authorId,
             videoCount: firstPage.videoCount,
+            isListed: firstPage.isListed,
             videos: allVideos
         ).toPlaylist(baseURL: baseURL)
 
@@ -351,7 +353,7 @@ actor InvidiousAPI: InstanceAPI {
             )
         }
 
-        return RemotePlaylistSnapshot(playlist: playlist, entries: entries)
+        return RemotePlaylistSnapshot(playlist: playlist, entries: entries, isListed: firstPage.isListed)
     }
 
     /// Runs the snapshot assembly over raw page payloads, decoding them the way
@@ -704,35 +706,38 @@ actor InvidiousAPI: InstanceAPI {
 
     /// Edits a playlist's title, description or privacy.
     ///
-    /// Title and privacy are sent even when unchanged: Invidious reads a missing
-    /// field as "leave it alone" for the description but validates the other two
-    /// on every request, so a partial body is rejected rather than merged.
-    /// Answers 204 with no body.
+    /// The title is sent even when unchanged: Invidious reads it out of the body
+    /// without a default and answers 403 `Missing hash key: "title"` when it is
+    /// absent (measured). The other two fields fall back to what is stored, so
+    /// omitting them is how the server is told to keep them — which is the only
+    /// way to leave a playlist's visibility alone, since the API never says
+    /// which of unlisted and private it currently is. Answers 204 with no body.
     /// - Parameters:
     ///   - id: The playlist ID
     ///   - title: The title to store
     ///   - description: The description to store, or `nil` to leave it alone
-    ///   - privacy: The visibility to store
+    ///   - privacy: The visibility to store, or `nil` to leave it alone
     ///   - instance: The Invidious instance
     ///   - sid: The session ID from login
     func updatePlaylist(
         id: String,
         title: String,
         description: String?,
-        privacy: PlaylistPrivacy,
+        privacy: PlaylistPrivacy?,
         instance: Instance,
         sid: String
     ) async throws {
         struct UpdateRequest: Encodable, Sendable {
             let title: String
-            let privacy: String
+            /// Omitted from the JSON when nil, which keeps the stored visibility.
+            let privacy: String?
             /// Omitted from the JSON when nil, which is how the server is told
             /// to keep the description it already has.
             let description: String?
         }
 
         let body = try JSONEncoder().encode(
-            UpdateRequest(title: title, privacy: privacy.rawValue, description: description)
+            UpdateRequest(title: title, privacy: privacy?.rawValue, description: description)
         )
         let endpoint = GenericEndpoint(
             path: "/api/v1/auth/playlists/\(id)",
@@ -1818,6 +1823,9 @@ private struct InvidiousPlaylist: Decodable, Sendable {
     let author: String?
     let authorId: String?
     let videoCount: Int
+    /// The whole of what Invidious says about visibility: `privacy.public?`,
+    /// serialised. Unlisted and private are both `false` and indistinguishable.
+    let isListed: Bool?
     let videos: [InvidiousPlaylistItem]?
 
     nonisolated func toPlaylist(baseURL: URL) -> Playlist {