Respect machine Z speed limits in generated travel

[highpowerxh]

Description

Closes #970 for the generated travel-feedrate defect. This PR targets main independently of the acceleration-preset-only PR #990; it changes no printer or material presets.

• Cache the normal machine_max_speed_z value and cap pure-Z travel, lift/unlift, and spiral lift when the limit is positive. Preserve explicit travel_speed_z, its zero-value active-travel fallback, and first-layer fallback behavior, regardless of whether machine-limit commands are emitted.
• Cap the Z component of straight XYZ travel using the emitted, quantized segment endpoints. Round capped feedrates down so output formatting cannot push the component over the limit. Track the intermediate endpoint after normal, lazy, and spiral hops, avoiding an unnecessary slowdown of the following horizontal segment. Spiral lift retains a conservative overall feedrate cap.
• Keep the writer's physical Z until deferred layer-change travel is emitted, instead of silently assigning the upcoming layer Z. A scheduled force_z lift preserves the requested hop height above the new layer.
• Add writer regressions and an end-to-end exported layer-change regression; update the related configuration documentation comment.

No dependencies or profile migrations are introduced. This fixes an objectively excessive generated feedrate, not the separate excessive preset acceleration tracked in #989. It does not establish the root cause of mechanical height loss or guarantee against missed steps. User-authored G-code and firmware bed compensation are outside this change's scope. The reported successful hardware print at Z acceleration 500 mm/s² and Z speed 10 mm/s did not isolate this code change.

Screenshots/Recordings/Graphs

No UI changes. The reported straight segment from X167.804 Y167.985 Z0.3 to X167.921 Y167.804 Z0.5 previously requested F6000, approximately 68.02 mm/s in Z despite a 40 mm/s limit. Its regression now requires:

G1 X167.921 Y167.804 Z.5 F3528.285

Tests

Native validation was run in the existing arm64 macOS parent worktree:
/Users/HighPower/repo/copilot-worktrees/OrcaSlicer/highpowerxh-issue-970-z-hop-speed-is-not-limited-by-machine-ma-0f8657.

• cmake --build build/arm64 --target fff_print_tests --parallel 6: passed in the fresh native rebuild on October 11.
• build/arm64/tests/fff_print/fff_print_tests.app/Contents/MacOS/fff_print_tests: passed 844 assertions across 38 test cases in the fresh rerun (seed 724905872).
• cmake --build build/arm64 --target Snapmaker_Orca fff_print_tests --parallel 6: passed on October 10 after the final deferred-layer fix.

Coverage includes pure-Z fallback/explicit speeds, first-layer fallback, limit refresh, machine-limit emission enabled/disabled, ascending/descending and shallow XYZ geometry, output coordinate quantization, normal/lazy/spiral hops, lift restoration, the exact offending segment above, and deferred layer-change G-code export.

The transferred six-file patch and this branch's diff have identical SHA-256:
c9574a831c1634e8ceca0cf94dc9c643a1bb032d35d26ebeb29cfc5a2bb6e6d8.
The parent tested checkout is at b7012d11fec7c035365fe7c5e9ca6764f211fbe9, based on 42657f9bdae6d8eee54a54ba634d833c67565fe9, with separate acceleration-preset commits and the same six-file code/test patch. This PR is based on current main, 441f73cc8d91d84f574a9d910e84fb8eeb099cf5; that newer baseline removes shell/paint-penetration validation in Print.cpp and related GUI code (#986). Those baseline changes are not part of this PR.

In this independent checkout, git apply --check, git apply --reverse --check, and git diff --check all passed; transfer needed no conflict resolution. No native build was run in this fresh checkout, avoiding a duplicate dependency build. Physical printer behavior has not been isolated or validated for this patch.