[Tech debt] Infrastructure references Persistence, breaking the layer rule

Overview

CLAUDE.md states that Infrastructure and Persistence are siblings, both depending only on Application and Domain. In fact DfE.CheckPerformanceData.Infrastructure.csproj declares a ProjectReference to Persistence, and exactly one file uses it.

One class is holding open a permanent, invisible licence for every future Infrastructure class to reach into the database directly, bypassing Application entirely.

Evidence

src/DfE.CheckPerformanceData.Infrastructure/Queue/PostgresQueueService.cs:6-7 — the only two using DfE.CheckPerformanceData.Persistence.* lines in the whole project:

using DfE.CheckPerformanceData.Persistence.Contexts;   // IPortalDbContext
using DfE.CheckPerformanceData.Persistence.Entities;   // QueueMessageEntity

Proposed fix

Move PostgresQueueService into the Persistence project — it is a database-backed queue implementation of an Application interface, so Persistence is where it belongs by the same rule that puts repositories there. Move its DI registration from the Infrastructure DependencyManager to the Persistence one, then delete the ProjectReference from Infrastructure.csproj.

Acceptance criteria

• PostgresQueueService lives in Persistence and is registered by Persistence/DependencyManager.cs.
• Infrastructure.csproj no longer references Persistence.
• The corresponding architecture test from the fitness-test ticket is unskipped and passing.
• Existing queue tests still pass with no behavioural change.