Clarify safe Radarr media and sidecar repair

[slashmad]

What changed

• treats visible archive-derived Radarr media as a healthy informational packed-media state instead of a hardlink problem
• offers hardlink-missing only when exactly one visible selected qBittorrent video has the same byte size as the managed movie
• fails closed with manual unmatched/ambiguous statuses when there are zero or multiple same-size candidates
• separates the primary movie action from optional subtitles, NFO, and other sidecars in Reconcile
• labels already-valid primary media as a sidecar-only repair and leaves the movie untouched
• adds regression coverage proving sidecar-only repair does not hash the primary movie

Why

An existing movie can be correct but stored as a normal copy rather than a hardlink, while archive-derived media has no applicable hardlink identity at all. The previous audit and plan presentation could conflate those cases with missing sidecars and make the intended mutation unclear.

The new classification keeps automation narrow: byte size and inode identity identify only one candidate; exact content identity is still proven by SHA-256 during execution before a library copy can be replaced.

Safety impact

• no hardlink repair is proposed without one unique same-size direct qBittorrent candidate
• zero or multiple candidates remain manual
• packed media is never offered as standalone hardlink repair
• sidecar-only jobs skip media hashing and do not replace, move, or delete the primary movie
• conflicting sidecars remain disabled and are not overwritten automatically

Relevant invariants: INV-AUTO-001, INV-ARCHIVE-001, INV-HARDLINK-001, and INV-AMBIGUITY-001.

Validation

• 133 Python unit tests passed
• Ruff passed
• MyPy passed
• Bandit passed
• ESLint passed
• HTML Validate passed
• Stylelint passed
• git diff --check passed