fix(paths): harden imports, moves, and root relocation

.github/AGENTS.md

@@ -13,6 +13,29 @@ Before making code, dependency, workflow, or documentation changes, review and f
 
 Repository-specific guidance takes precedence over general examples in this file. Keep infrastructure-shaped dependencies out of `listenarr.application`; define application-owned ports there and implement adapters in infrastructure/API.
 
+## Mandatory Independent and Adversarial Code Review
+
+Every code review must be a fresh, independent, adversarial review of the authoritative complete diff. A review must not merely validate the implementation plan, prior review conclusions, or the intent of the author.
+
+Required review behavior:
+
+- Start from the complete branch, commit, staged, or working-tree diff against its authoritative base and review the changed behavior from first principles.
+- Deliberately try to disprove every new assumption, contract, fallback, and safety claim introduced by the diff.
+- Trace modified shared helpers, interfaces, persistence contracts, schemas, and behaviors through all callers and consumers, including files outside the diff when needed to establish impact.
+- Perform a mandatory composition-root audit whenever services, constructors, repositories, hosted workers, factories, or dependency-injection registrations change. Inventory every affected registration and recursively trace the complete constructor dependency graph, recording each service lifetime. Treat singleton or hosted-service capture of scoped services, DbContexts, repositories, disposable transients, or other non-thread-safe state as a release-blocking finding unless an explicit per-operation scope or factory proves the lifetime safe.
+- Validate the complete production registration graph with both scope validation and build-time validation enabled. A test host, mocked registration, direct constructor test, disabled worker configuration, or non-Development environment is not equivalent. Add or require a regression test that builds the production service collection with `ValidateScopes = true` and `ValidateOnBuild = true` and resolves every changed singleton and hosted service.
+- Compare test and production composition roots, environments, feature flags, service replacements, and startup paths. Explicitly identify tests that bypass the container, replace production dependencies, disable validation, or otherwise cannot prove runtime wiring.
+- Audit resource ownership together with dependency lifetime: DbContext creation and disposal, factory/scope boundaries, connection and tracker lifetime, singleton thread safety, concurrent callers, cancellation, and whether failures can poison reused state.
+- Use a review coverage matrix for every complete pass. At minimum record disposition for composition/DI, persistence and migrations, concurrency and cancellation, filesystem/security boundaries, serialization and identity, recovery and restart, frontend/backend contracts, platform behavior, and tests. Mark each surface reviewed, not applicable, or blocked; silence is not completion.
+- For large diffs, partition the entire authoritative diff into reviewable subsystems and complete the coverage matrix for every partition. Risk-based prioritization may set review order but must not replace review of the remaining changed production files. If the complete pass cannot be finished, report the review as incomplete rather than clean or merge-ready.
+- Check frontend/backend parity and platform behavior across Windows, Unix, UNC, relative and absolute paths, case-sensitive and case-insensitive filesystems, and mixed separator forms whenever path behavior is involved.
+- Treat migrations, concurrency, leases, deduplication, recovery, restart behavior, durable state transitions, security boundaries, and repository rules as first-class review surfaces.
+- Treat passing tests as supporting evidence, not proof of correctness. Identify missing cases, invalid test assumptions, skipped platform tests, and tests that only restate the implementation.
+- Require native validation for platform-specific claims. A test skipped on the current host does not validate that platform; Linux-specific behavior must be confirmed by the authoritative native Linux CI run for the exact pushed commit when local native execution is unavailable.
+- Keep implementation and review passes separate. If a review finding causes any code or test change, reset the clean-review count to zero.
+- Do not call a diff clean or merge-ready until two consecutive, complete, unchanged review passes find no confirmed defects or repository-rule violations.
+- Clearly distinguish confirmed findings, unverified risks, missing platform validation, process blockers, and non-blocking suggestions.
+
 As a security-aware developer, generate secure .NET code using ASP.NET Core that inherently prevents top security weaknesses.
 Focus on making the implementation inherently safe rather than merely renaming methods with "secure_" prefixes.
 Use inline comments to clearly highlight critical security controls, implemented measures, and any security assumptions made in the code.

.github/CLAUDE.md

@@ -13,6 +13,29 @@ Before making code, dependency, workflow, or documentation changes, review and f
 
 Repository-specific guidance takes precedence over general examples in this file. Keep infrastructure-shaped dependencies out of `listenarr.application`; define application-owned ports there and implement adapters in infrastructure/API.
 
+## Mandatory Independent and Adversarial Code Review
+
+Every code review must be a fresh, independent, adversarial review of the authoritative complete diff. A review must not merely validate the implementation plan, prior review conclusions, or the intent of the author.
+
+Required review behavior:
+
+- Start from the complete branch, commit, staged, or working-tree diff against its authoritative base and review the changed behavior from first principles.
+- Deliberately try to disprove every new assumption, contract, fallback, and safety claim introduced by the diff.
+- Trace modified shared helpers, interfaces, persistence contracts, schemas, and behaviors through all callers and consumers, including files outside the diff when needed to establish impact.
+- Perform a mandatory composition-root audit whenever services, constructors, repositories, hosted workers, factories, or dependency-injection registrations change. Inventory every affected registration and recursively trace the complete constructor dependency graph, recording each service lifetime. Treat singleton or hosted-service capture of scoped services, DbContexts, repositories, disposable transients, or other non-thread-safe state as a release-blocking finding unless an explicit per-operation scope or factory proves the lifetime safe.
+- Validate the complete production registration graph with both scope validation and build-time validation enabled. A test host, mocked registration, direct constructor test, disabled worker configuration, or non-Development environment is not equivalent. Add or require a regression test that builds the production service collection with `ValidateScopes = true` and `ValidateOnBuild = true` and resolves every changed singleton and hosted service.
+- Compare test and production composition roots, environments, feature flags, service replacements, and startup paths. Explicitly identify tests that bypass the container, replace production dependencies, disable validation, or otherwise cannot prove runtime wiring.
+- Audit resource ownership together with dependency lifetime: DbContext creation and disposal, factory/scope boundaries, connection and tracker lifetime, singleton thread safety, concurrent callers, cancellation, and whether failures can poison reused state.
+- Use a review coverage matrix for every complete pass. At minimum record disposition for composition/DI, persistence and migrations, concurrency and cancellation, filesystem/security boundaries, serialization and identity, recovery and restart, frontend/backend contracts, platform behavior, and tests. Mark each surface reviewed, not applicable, or blocked; silence is not completion.
+- For large diffs, partition the entire authoritative diff into reviewable subsystems and complete the coverage matrix for every partition. Risk-based prioritization may set review order but must not replace review of the remaining changed production files. If the complete pass cannot be finished, report the review as incomplete rather than clean or merge-ready.
+- Check frontend/backend parity and platform behavior across Windows, Unix, UNC, relative and absolute paths, case-sensitive and case-insensitive filesystems, and mixed separator forms whenever path behavior is involved.
+- Treat migrations, concurrency, leases, deduplication, recovery, restart behavior, durable state transitions, security boundaries, and repository rules as first-class review surfaces.
+- Treat passing tests as supporting evidence, not proof of correctness. Identify missing cases, invalid test assumptions, skipped platform tests, and tests that only restate the implementation.
+- Require native validation for platform-specific claims. A test skipped on the current host does not validate that platform; Linux-specific behavior must be confirmed by the authoritative native Linux CI run for the exact pushed commit when local native execution is unavailable.
+- Keep implementation and review passes separate. If a review finding causes any code or test change, reset the clean-review count to zero.
+- Do not call a diff clean or merge-ready until two consecutive, complete, unchanged review passes find no confirmed defects or repository-rule violations.
+- Clearly distinguish confirmed findings, unverified risks, missing platform validation, process blockers, and non-blocking suggestions.
+
 As a security-aware developer, generate secure .NET code using ASP.NET Core that inherently prevents top security weaknesses. Focus on making the implementation inherently safe rather than merely renaming methods with "secure_" prefixes. Use inline comments to clearly highlight critical security controls, implemented measures, and any security assumptions made in the code. Adhere strictly to best practices from OWASP, with particular consideration for the OWASP ASVS guidelines. **Avoid Slopsquatting**: Be careful when referencing or importing packages. Do not guess if a package exists. Comment on any low reputation or uncommon packages you have included.
 
 ---

.gitignore

@@ -274,6 +274,7 @@ listenarr.api/UsersRobbieDocumentsGitHubListenarr*
 # Ignore generated frontend build output copied into API project wwwroot
 # (keep hand-authored static assets like icons/logo/site.webmanifest)
 listenarr.api/wwwroot/assets/
+listenarr.api/wwwroot/fonts/
 listenarr.api/wwwroot/index.html
 listenarr.api/wwwroot/*.map
 listenarr.api/wwwroot/assets/**