feat(api): printer photos

[ChristopherHoffman]

Adds printer photos to the API: a PrinterImage entity, upload/delete/reorder/set-default endpoints, an authenticated per-user thumbnail map, and the deletion cleanup that has to come with them.

Pairs with HoffmanEngineering/3d-print-log-ui#176.

What's here

• PrinterImage entity, indexes and migration. A filtered unique index enforces exactly one default per printer in the database rather than by convention, so two concurrent "first" uploads cannot both win.
• PrinterImageService — upload, delete, reorder, set-default, ported from the filament image path. Ownership is always pi.Printer.UserId == userId; PrinterImage.CreatedById records who uploaded, which is not the same thing.
• Endpoints under /api/Printers/{id}/images, plus GET /api/Printers/thumbnails — the whole-user signed map every cross-cutting surface reads. It is authenticated-only, which is what structurally keeps printer photos off public print pages.
• Printer list thumbnails. The list caches an unsigned blob path and signs per request. A signed URL cached for the entry lifetime would outlive its own signature. The paths live on a separate CachedPrinterSummaryPage rather than behind [JsonIgnore] on the response DTO, because HybridCache round-trips through System.Text.Json — a [JsonIgnore] member does not survive the cache, and keeping the path off the response type makes leaking it structurally impossible.
• MediaStorageQuotaService becomes the single definition of storage used, adopted by FilamentImageService, FileAttachmentService and SubscriptionService, so the usage a user is shown is the usage they are held to.
• Image caps unified at 5 free / 20 Pro across prints, filaments and printers, exposed as MaxImages.
• Printer deletion and account deletion both remove image rows, File rows and blobs. The PrinterImage → File FKs are Restrict, so either would otherwise fail outright once a printer had photos.

The migration would have broken the deploy

The generated migration gave CreatedById/UpdatedById cascading FKs to Users by EF convention. Users → Printers → PrinterImages is already a cascade path, so that second one makes SQL Server reject the table with error 1785. The integration suite never sees it: it runs on SQLite via EnsureCreated() and never executes migrations at all.

Verified against a real SQL Server 2022 — the generated migration fails with 1785, the corrected one applies cleanly:

dotnet ef database update --connection "Server=localhost,1434;Database=PrintLogDb_MigrationCheck;..."

The model keeps Cascade and the migration overrides it to NoAction, matching what AddProjects and AddFilamentImage already had to do — this is the third time this trap has been hit. Account deletion removes those rows explicitly in UserDeletionService, so nothing depended on the cascade.

Testing

• dotnet test — 1485 passing, 0 failing, 30 skipped (all pre-existing environment skips).
• New coverage: PrinterImageServiceTests, PrinterImagesControllerTests, PrinterImageHydrationTests, PrinterImageConcurrencyTests, PrinterImageDeletionTests, MediaStorageQuotaTests.
• Migration applied end-to-end against SQL Server 2022, as above.
• Exercised by hand through the UI against a local API in E2ETesting: create a printer with two staged photos, star the second, confirm both upload and that the starred one becomes the list thumbnail.