Fix #95: engine-aware 360/720 DPI support

[boingball]

Summary

Adds Issue #95 DPI support on top of the current slow-Canon work in #94.

This PR deliberately targets fix/canon-large-job-upload, so its diff is only the DPI work. Once #94 is ready, this can be merged into it without losing the Canon large-job/back-pressure changes.

What changes

• accepts reported square 300 / 360 / 600 / 720 DPI modes instead of hard-coding 300/600
• keeps generic printer, PWG Raster, and Apple Raster (URF) resolution capabilities separate
• requests/parses urf-supported RS... resolution values
• uses pwg-raster-document-resolution-supported for PWG when the printer supplies it
• falls back to generic printer-resolution-supported for older/incomplete printers and legacy capability caches
• preserves the existing 300 compatibility override* for PWG/URF (including the Canon case)
• stops the runtime config loader from silently coercing RESOLUTION=360 or RESOLUTION=720 back to 300
• scales printer.device MaxDots/XDotsInch/YDotsInch from the selected DPI instead of the old binary 300/600 switch
• bumps the driver to 41.19
• keeps asymmetric modes such as 1440x720 hidden for now because MintPRINT currently stores one capture DPI for both axes

Epson ET-2850 / #95

The supplied probe reports generic 360x360 and 720x720, but PWG Raster reports only 360x360 and URF reports RS360. Accordingly MintPRINT will not blindly send a 720-DPI PWG/URF stream that the decoder did not advertise. On this printer PWG/URF should offer reported 360 DPI plus the existing marked 300* compatibility choice; engines using the generic resolution capability can offer 360/720.

Regression safety

The branch is based exactly on #94 head 1a3193a32e30f6be52125a22357d5182b4eaa6eb.

Full host-side make check passes after the patch, including DPI, JPEG, URF, media-size, HTTP/IPP parsing, mDNS, PostScript and graphics-boundary regressions.

Fixes #95