Design format: a change is one new file, never an edit to FORMAT (#1563)

A PR that saves something new adds crates/doc/src/format/pending/<name>.rs (a note, and an upgrade step if older designs must be rewritten). The build writes the next format number while changes are pending and lists them in format_pending; scripts/fold-format-pending.sh fixes them as v<N>/ at release time. Formats 23 and 24 move into v23/ and v24/.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crates/doc/src/format/pending/README.md

@@ -0,0 +1,27 @@
+# Pending design-format changes
+
+One file per change to what a design file saves that no release has shipped yet. Adding a file
+here is the whole format bump: never edit `FORMAT`, `JSON_STEPS` or another change's file.
+
+- Name it after the change, lowercase with dashes: `placed-plane-origins.rs`.
+- Start it with a `//!` note: what is saved, what an older design gets without it, and what
+  the last release does with a design that has it (it refuses the newer format number).
+- If older designs must be rewritten as they open, add the step to the same file:
+
+  ```rust
+  //! …the note…
+  use serde_json::Value;
+
+  pub fn step(v: &mut Value) -> crate::Result<()> {
+      // rewrite the design's JSON here
+      Ok(())
+  }
+  ```
+
+  Steps run in file-name order, after the steps of every older format.
+
+While this folder has a change in it, the build writes the next format number (the last
+folded one + 1, which no release reads), and lists the changes a file has in its
+`format_pending` field, so a later build applies only the steps that file is missing. At release
+time `scripts/fold-format-pending.sh` moves these files into `../v<N>/`, which fixes that number
+for good. See `crates/doc/src/format.rs` and CONTRIBUTING.md.

crates/doc/src/format/v23/import-fcstd-3dm.rs

@@ -0,0 +1,4 @@
+//! An Import's `file` can name a FreeCAD `.FCStd` or Rhino `.3dm` file (#1435, read through
+//! cadmpeg); its `step` is still the STEP text the file was restated as, so the feature's fields
+//! are unchanged and version 22 designs need no transformation; 0.13.x asks for an update before
+//! it meets these imports.

crates/doc/src/format/v23/motion-link-coupling.rs

@@ -0,0 +1,7 @@
+//! A motion link can carry a `coupling`: a gear pair (`ra`, `rb`, `internal`), a rack and pinion
+//! (`radius`) or a screw (`pitch`), each size a number in mm, an expression or a picked round
+//! face, and `reverse`. The link's `ratio` is worked out from it whenever the design changes and
+//! saved as well, so a link reads the same without it. Version 22 designs need no
+//! transformation: a link without `coupling` is a plain motion link, as it always was; 0.13.0
+//! (which reads up to 22) asks for an update instead of keeping a gear's ratio when its radius
+//! changes.

crates/doc/src/format/v24/edge-flange-corner-relief.rs

@@ -0,0 +1,5 @@
+//! An Edge Flange feature can choose its own corner relief (`corner_relief_shape`: notch, round,
+//! rectangular or tear, and `corner_relief`, the size across), for the corners its flanges make.
+//! Version 23 designs need no transformation: a feature without them follows the sheet metal
+//! rule, as it always did, and saves as before; 0.13.0 (which reads up to 22) asks for an update
+//! instead of silently building the rule's relief where a design asks for another.