feat(player): a bookmark reopens every player as it was, once

The Plex player names the playlist it plays through (v=player:<id>:playlist:<pid>), so a bookmark
rebuilds the queue from the playlist's own order while the item is still in it.

Found in the browser and fixed:
- after a reload the shell's player opened a second one over Home and the feed: it read the catalog
  row the page had fetched (a disabled query still reads the shared cache); it now waits for ready.
- every reload under an open overlay left a dead history step: the first overlay to open takes over
  the entry the document was loaded on.
- the feed's address was implicit, the same as the start-page landing, so a reloaded or bookmarked
  feed opened as Home: the feed now names itself (page=feed) like every page.
- a linked file or video that is gone was said, but stayed in the address and was said again on
  every reload: its keys are taken off.

The overlay address is written in one place (the entry is named once it is current), and the player
keys only the codec reads are no longer exported.

frontend/src/lib/urlState.ts

@@ -233,6 +233,13 @@ export function urlWithParams(updates: Record<string, string | null>): string {
   return hrefHere(params);
 }
 
+/** Take `keys` off the current entry's address: what a link named and the page could not show (a file
+ *  or a video that is gone, said once) must not stay to be said again on every reload, or shared. */
+export function dropFromAddress(keys: readonly string[]): void {
+  const updates = Object.fromEntries(keys.map((k) => [k, null]));
+  window.history.replaceState(window.history.state, "", urlWithParams(updates));
+}
+
 /** The channel page's address, opened over the page on screen: the shell's own keys (the page, an
  * entry link not yet read) and the channel — none of the page's keys, none of another channel's view
  * (the channel page writes its own, lib/channelPageUrlState), and no player (opening a channel closes