M7: Header & footer: shrink the page content out of their way (#2140)

[switch87]

Fixes #2140

What

Acrobat's Header & Footer dialog can shrink the page so the header, footer or Bates number doesn't land on the page's own text and graphics. PdfCraft only drew on top of the page. This PR adds that option, in the engine, the automation tool and the dialog. Bates numbering opens the same dialog, so it gets the option too.

• HeaderFooter::shrink (crates/edit): the page's original content is scaled down evenly into the band the header and footer leave free (HeaderFooter::bands: the margin, the lines of the tallest box, and half the font size of clearance), centred across the page. A side with no text keeps its space. The scaling happens in display space, so a rotated page shrinks the way it is shown.
• The scale is one small content stream placed first inside the existing q/Q wrapper and tagged as part of the header and footer. Remove and Update take it away again, Update never shrinks twice, and a background behind the page stays full size.
• If the margins leave no room on any selected page, the request is refused before anything is drawn or replaced.
• doc_header_footer takes shrink: true.
• Dialog: a "Shrink the page content to make room for the header and footer" checkbox. The schematic preview shows the band the content shrinks into. The label is translated in all 22 catalogs, and their checksums in ATTRIBUTION.toml are updated.
• Parity: edit.header-footer-shrink goes from planned to shipped, with its limits in the notes. ROADMAP progress log line added.

Not done yet (also in the parity notes): annotations (links, comments, form fields) and PdfCraft's own added text and images stay where they are. They are not moved with the content.

Rendered with pdfcraft-cli (synthetic page; header ACME Corp. - Confidential, Bates ACME-000001, 12 pt), before and after:

The dialog:

Tests

• crates/edit: the exact scale and placement on an upright page, a rotated page (display space), Remove/Update undoing the shrink without stacking it (back to the exact original content), and the no-room refusal leaving the document unmodified. I checked that all four fail with the shrink disabled.
• crates/automation: end to end. The moved text is read back from a saved copy (scale and centring), the no-room refusal is checked, and Remove brings the text back to its original box. This test fails without the tool argument.
• crates/ui-egui (ui_group/marks.rs): Bates numbering opens the dialog, the checkbox turns on the shrink, and OK applies it. This test fails without the checkbox.

Run locally: cargo fmt --all --check, cargo clippy -p pdfcraft-edit -p pdfcraft-automation -p pdfcraft-ui-egui -p pdfcraft-engine --all-targets -D warnings, the tests of pdfcraft-edit, pdfcraft-automation, pdfcraft-ui-egui (lib, including the catalog-coverage tests, and ui_group) and the header/marks tests of pdfcraft-engine, plus cargo xtask layers, assets and parity. I couldn't run the wasm check locally, so CI covers that.