fix(add-video/add-audio): de-collide different sources sharing a basename

[renezander030]

Fixes #37 (reported by @naoyashiga).

Problem

addVideo/addAudio copy each source into assets/<kind>/<basename> and skip the copy when the destination already exists. The skip is intentional and load-bearing — the Wikimedia fetch path pre-writes into that dir, and re-adding the same file must not re-copy. But when a different source resolves to a basename that's already present (e.g. en/0_00.png vs jp/0_00.png), the copy is skipped silently and the draft ends up pointing at the first file's content, with no error or warning.

Fix

Both functions now route through a shared copyAssetDeduped():

• Destination absent → copy (unchanged).
• Destination present, byte-identical → silent no-op (preserves Wikimedia idempotency and cheap re-adds).
• Destination present, different source → write under a content-hashed name (0_00.<sha1-8>.png) and print a warning to stderr. The draft references the correct content instead of a stale one.

This goes one step past the warning-only suggestion in the issue: warning-only would surface the collision but still leave the draft pointing at wrong media. De-colliding by content makes the draft correct.

Note: the warning is written to stderr, so JSON stdout output stays clean.

Tests

test/asset-collision.test.mjs:

• Two different sources sharing a basename → two distinct assets on disk, two distinct material paths whose content matches their originals, and a collision warning on stderr.
• Re-adding the same file → idempotent no-op (single copy, no warning).

Full suite green (218 tests).

Follow-up (not in this PR)

replace.ts mirrors this copy pattern; a separate change could route it through the same helper for consistency.