fix: dedupe render-stage adds to prevent ghost re-renders

[JRemitz]

Summary

A user-reported bug: with 3 clips already rendered, 1 errored, and 3 pending, clicking "Render all" silently re-rendered one of the already-rendered clips (overwriting the output file on disk), while the errored clip stayed put.

Root cause traced to three things compounding:

1. addToStage (renderQueue.svelte.ts) just appends — no check for an existing pending stage item with the same clipPath.
2. isClipInStage (= isClipInQueue alias) only matches pending stage items. Once a clip is rendered and moves to the CLI publish queue, no warning shows on re-add.
3. reeln-cli/reeln/commands/render.py:123 derives the output filename purely from the source clip stem ({stem}_short.mp4). Two stage items pointing at the same source clip render to the same output and silently overwrite each other.

Fix

• addToStage refuses an add when an item with the same clipPath is already pending OR already in the CLI publish queue (logs an info-level "Refused duplicate" message instead of throwing).
• New isClipInCliQueue(clipPath) derives the expected {dir}/shorts/{stem}_*.mp4 pattern and checks against cliItems.
• ClipReviewPanel's yellow warning now shows two distinct messages: "already pending in the render queue" vs. "already been rendered (in the publish queue)."

renderAll correctly skipping status !== "pending" was the bit that worked — that's why the errored clip didn't retry, matching the user's observation.

Test plan

• npm test — full suite 115/115 green; 4 new tests cover dedup behaviour (pending, CLI queue, unrelated-clip negative case).
• npm run check — 0 errors (41 pre-existing a11y warnings unchanged).
• Manual: stage a clip, render it, then try to re-stage from the same event → should see the new "already been rendered (in the publish queue)" warning.

🤖 Generated with Claude Code