fix(archon,paroche): persist want and release rows before enqueue, on both surfaces

[forkwright]

Two issues, and the more interesting result is that #644's premise did not survive reading the code.

#651 — releases and wants were never persisted before enqueue

handle_enqueue (MCP) resolved release_id against eksetasis's in-memory cache and minted a random want_id when the caller omitted one, then enqueued — without either row reaching the database. syntaxis::DownloadQueue::enqueue only writes download_queue. So the happy path downloaded bytes and then deterministically failed at import, where ImportAdapter requires both rows to exist.

The HTTP route paroche::routes::download::enqueue_download had the identical defect, taking client-supplied ids at face value. An issue that names one surface does not mean only one surface carries the defect, so both are fixed here.

Both now require an existing want_id, validated against apotheke::repo::want, and idempotently upsert the releases row before calling queue.enqueue().

The shared rule lives in one place — paroche::routes::download, the lower point in the dependency graph, since archon already depends on paroche and not the reverse. What stays separate is only the error rendering: HTTP maps to ParocheError (404/409/500), MCP to tool_error text. That mapping is genuinely surface-specific; the persistence rule now has exactly one definition.

For the self-supplied-URL path there is no server-side resolve to draw metadata from, so magnet dn/xl parameters are parsed where present and a placeholder is used otherwise.

#644 — the issue's literal fix would have left the feature dead

HarmoniaEvent::PlexNotifyRequired has no production sender anywhere in the tree. Every occurrence outside the enum definition is inside syndesmos's own tests. The real import pipeline (kathodos) emits only ImportCompleted, and nothing bridges the two. Widening the event and "threading it through the senders", as the issue asks, would have threaded it through test-only senders and changed nothing at runtime.

What was fixed is the part that is real: the event now carries media_type, notify_plex_import takes it, and the wasteful refresh_all_plex_sections — which refreshed every configured Plex section on every import — is replaced by a targeted notify_library_scan. notify_library_scan is decoupled from &PlexClient in favour of the section map it actually holds, and notify_library_scan_by_section drops to private as the issue asked.

Deciding whether kathodos should fire PlexNotifyRequired, or syndesmos should subscribe to ImportCompleted, or a translator should exist, is an architecture call outside this issue's scope. Plex notification remains unreachable end-to-end until that is settled — stated plainly rather than left implied by a green diff.

Verification

The ordering tests are the load-bearing ones: each records whether the releases row existed at the instant enqueue() ran, so they fail if the persist is ever moved after the enqueue rather than merely checking the end state. That was confirmed by temporarily moving the call and watching them fail.

Also fixed, both pre-existing: archon/tests/mcp_acquisition_acceptance.rs did not compile under --all-targets, and acquisition_integration.rs's helper minted an unpersisted want_id that would now 404 across six tests.

On the build box, CI-exact: fmt clean, clippy --all-targets -D warnings clean, 2285/2285 tests passed, doctests passing.

Refs #651
Refs #644