Submit repeated label copies as one IPP print job #433

The print form currently expands Copies into repeated label entries (ui/src/pages/print/PrintForm.tsx). For a single template, src/batch.rs renders each entry separately and makes one print unit per label; src/driver.rs submits one IPP Print-Job per unit without the standard copies job attribute.

For example, printing three identical labels renders the same label three times and submits three jobs. It should render one document and submit one job requesting three copies on a printer that supports it.

The refactored ptouch-print-server supports PNG copies in a single job, and defines one IPP job as one physical batch: PR #47, revision 0603578c02a577e61b6a50abc08a5fef3975a320. Three separate jobs unnecessarily introduce three batch boundaries; one job with three copies gives the server the intended copy and finishing boundaries.

Scope

Preserve copy multiplicity through the print path and carry it through the existing print options and IPP request builder using the standard integer copies attribute. Apply this to copies of a single label, including repeated copies of a source row in Connect and Import. Keep distinct labels in their existing order; this is not a request to combine different labels into one document or add a raster conversion pipeline.

Downloads and sheet pagination keep their existing behavior. Retain per-label validation, physical-label limits, media geometry, print summaries and failure-to-row mapping. This changes the current rendering spec's one-job-per-label rule and needs an OpenSpec change.

Acceptance

• A supported printer receives exactly one Print-Job with copies=3 for three copies of one single-template label; render that document once.
• One copy remains one job with one effective copy.
• Two different labels requested with three copies each produce two jobs, in label order, each requesting three copies. Their data and resolved lengths remain distinct.
• The selected finishing policy applies to that one job's copies. When the continuation choice from Support client-controlled label cuts through IPP finishings #430 is available, carry it once per job so the server can separate internal copies and hold the final end.
• Summary counts describe physical labels and submitted jobs accurately: the three-copy example reports total=3, sent=3, jobs=1 when accepted. If its submission fails, all three represented label indices are reported failed and Connect/Import still annotate the correct source row.
• Respect advertised printer copy support; never silently reduce the requested copy count or report unprinted copies as sent.
• Capture actual outgoing IPP requests in tests, including copy type/count, job count, finishing, media dimensions and failure mapping. Verify PT-2730 physical copy count and cutting through labeler before claiming hardware success.
• Preserve validate-before-send behavior and introduce no automatic replay after an uncertain submission.

Related: #430. Keep this copy/batch change separate from the capability-gated Chain and continue checkbox.