IPP backend exits 0 instead of retrying as raster after document-format-error and failed Cancel-Job

Before you write the report
Read the REPORTING_ISSUES.md file in the main repository and prepare data mentioned there which looks relevant to you issue.

Describe the bug

This appears to be reproducible again with CUPS 2.4.19 on Manjaro Linux.

Printer: Brother MFC 6900

With an IPP Everywhere queue, the printer advertises:

document-format-supported:
application/octet-stream
image/urf
image/pwg-raster
application/pdf

CUPS sends the job as PDF. The printer then reports document-format-error, and the backend correctly emits:

JOBSTATE: cups-retry-as-raster

However, the attempted Cancel-Job returns client-error-not-possible. The IPP backend then exits with status 0 and CUPS marks the unprinted job completed:

job-state-reasons: job-incoming,job-printing,
processing-to-stop-point,document-format-error
job-impressions-completed: 0
cancel_job() = client-error-not-possible
Unable to cancel print job.
PID (...) (/usr/lib/cups/backend/ipp) exited with no errors.
Job completed.

No raster retry occurs, despite the cups-retry-as-raster state and the printer advertising both PWG Raster and URF.

Configuring the same printer with a generic PCL driver works correctly, confirming that the printer and transport are operational.

This appears closely related to #391, but may be a regression or a distinct path caused by the failed Cancel-Job. Should #391 be reopened, or should this be tracked in a new issue?

Start with the IPP backend entry point at /usr/lib/cups/backend/ipp and trace the reported document-format-error path through cancel_job(). Reproduce with the Brother MFC 6900 scenario or an equivalent IPP queue, checking the cups-retry-as-raster state and failed Cancel-Job response. Done means a failed cancellation does not cause the backend to exit successfully without the expected raster retry, with regression coverage for this path.