JR-023: correct the missing-dependency logs, and test them

Both failure paths still told admins the overlay was "falling back to patching
index.html on disk". JR-021 deleted that fallback, so the message was false --
and it was false in the worst place, since an admin reads it precisely when
debugging a missing overlay and would go hunting for a patch that no longer
exists. They now name the install URL and say the overlay is disabled while
every other feature is unaffected. The not-found case is a Warning, not
Information: a headline feature being off should not sit among startup chatter.

UT-012..015 cover the branch. The File Transformation assembly is genuinely
absent from the test host, so TryRegister exercises its real not-found path
rather than a seam invented for the test. UT-015 pins that a null payload
returns empty rather than throwing -- this callback runs inside another
plugin's request path on every page served, so throwing would break the web
client itself, not just JRay's overlay.

Making those runnable needed the test project to reference Jellyfin.Controller
and Jellyfin.Model without the plugin's ExcludeAssets=runtime. My earlier claim
that DisableTransitiveFrameworkReferences alone sufficed was too narrow: it
drops the demand for the web *framework*, but ILogger and MediaBrowser.Common
live in the excluded assets, so anything past dependency-free logic failed at
run time with FileNotFoundException. Both settings are needed, and the register
now says so.

Second mutation check: downgrading the warning to Information fails UT-013 and
nothing else. Source restored and re-verified.

JR-023 reaches Done for the detection half. The config-page banner stays T4 --
verifiable only against a live server.

TRACES: UT-012, UT-013, UT-014, UT-015 | JR-023

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SPEC.md

@@ -477,13 +477,19 @@ Optionally, publish jRay through a repository manifest that also lists File
 Transformation, so one repository URL surfaces both. This is not a dependency
 mechanism; it removes a step and the chance of installing the wrong thing.
 
-**Current:** all three implemented. Startup detection and registration, a warning
-naming the plugin and its install URL, and a status banner on the configuration
-page fed by `GET /Plugins/JRay/Status/Dependencies` — satisfied, or missing with
-the manifest URL and what to do with it. The README now states the dependency
-before the install step rather than after it. **Gap:** no test executes the
-detection branch, so this stays `In Progress`; the config-page half is T4 and
-verifiable only against a live server.
+**Current:** all three implemented, and the detection half is tested
+(UT-012…015). Startup detection and registration, a warning naming the plugin
+and its install URL, and a status banner on the configuration page fed by
+`GET /Plugins/JRay/Status/Dependencies`. The README states the dependency before
+the install step rather than after it.
+
+Both failure-path log messages previously said the overlay was "falling back to
+patching index.html on disk" — a claim JR-021 made false, and the worst place to
+leave one: an admin reading it while debugging a missing overlay would go hunting
+for a patch that no longer exists. UT-013 asserts the message names the install
+URL and does *not* claim a fallback.
+
+**Gap:** the config-page banner is T4, verifiable only against a live server.
 
 ### JR-024 — Names render as text, never markup