Keep the online detail's download state on its own post

Two stale-state bugs came from react-router reusing the detail component
between posts (parent/child links hit the same /detail/<id> route):

- the previously viewed post's download panel kept rendering, so a freshly
  opened post could claim 'Downloaded to the library J-xx'. The task view is
  now gated on the task's post_id as well, and DetailPage keys the detail
  views per item — component state (download panel, delete confirmation,
  optimizer modal) cannot survive a post change any more.
- 'Your last download for this post finished' appeared on every revisit. It
  now only shows when this visit actually saw the download running (derived
  state, set during render), which still reports a re-attached download
  finishing while staying quiet on later visits; the 'In library' button
  remains the persistent indicator.

Library detail gets the same per-item key, so its delete confirmation and
optimizer modal reset between items too.

tsc, oxlint and the build are clean (the derived-state pattern was chosen
over a ref read in render / setState-in-effect, both flagged by the linter).

frontend/src/features/detail/DetailPage.tsx

@@ -14,11 +14,14 @@ export default function DetailPage() {
   if (J_ID_RE.test(itemId)) {
     if (!hasBackend()) return <BackendNeeded />;
     const normalized = `J-${itemId.slice(2)}`;
-    return <LibraryDetail jId={normalized} />;
+    // Key per item: remount so local state (delete confirm, optimizer, task
+    // view) cannot leak from the previously viewed item.
+    return <LibraryDetail key={normalized} jId={normalized} />;
   }
 
   if (/^\d+$/.test(itemId)) {
-    return <OnlineDetail postId={Number(itemId)} />;
+    // Key per post: the download task view must not survive a post change.
+    return <OnlineDetail key={itemId} postId={Number(itemId)} />;
   }
 
   return (