lidarr-decision-import: resolve Lidarr's stuck imports with Laya instead of an LLM

# lidarr-decision-import

A companion service for [Lidarr](https://lidarr.audio/) that resolves imports
Lidarr's own matcher gave up on - especially the case where a song was released
more than once (a standalone **Single**, an **EP**, and later a full **Album**)
and Lidarr can't tell which one a downloaded file actually belongs to.

It resolves those files with a **non-autoregressive decision model** rather than
a generative LLM. The model reads the file evidence and scores every candidate
release/track in a single forward pass, returning calibrated probabilities - so
there is no text generation, nothing to JSON-parse, and no hallucinated
confidence. This project uses [Laya](https://pypi.org/project/laya/), a
ModernBERT-based System 1 decision engine trained with reinforcement learning
against strictly proper scoring rules (RLCD).

## Why this isn't a "real" Lidarr plugin

Lidarr does have a plugin system (the `plugins` branch), but it only extends
**indexers**, **download clients**, and **notification connections** - it has no
extension point inside the core import/matching engine, which is exactly the part
that needs to change here. So this runs as a separate process that talks to Lidarr
over its REST API instead: it reads `/api/v1/manualimport`, asks the decision
model to disambiguate, and (optionally) submits the result back via the same
Manual Import API the Lidarr UI itself uses. No Lidarr branch switch required,
nothing installed into Lidarr itself.

## The workflow

**`resolve`** - polls Lidarr for anything sitting in Manual Import limbo. For each
file, it pulls every album/release/track for that artist (not just the one Lidarr
guessed), finds tracks with a similar title, and hands the decision model a
side-by-side comparison: which Single/EP/Album release does