docs(changeset): state the with_style_metadata break by signature, and the version it actually ships from (#3310)

* docs(changeset): state the with_style_metadata break by signature, and the version it actually ships from

The `rep-item-identity-across-boundary` changeset generates the Rust-API
paragraph of the next `@ifc-lite/cache`, `geometry`, `wasm` and
`server-client` CHANGELOG entries, so it is held to the code's accuracy bar.
Two things in it were not.

`6.0.0 → 6.1.0` was wrong when written and is wrong now: #3186 had already
bumped the Cargo workspace to `6.0.1`, and that commit is an ancestor of #3210,
which added this changeset. `Cargo.toml` on `main` reads `version = "6.0.1"`,
so the minor this changeset causes ships `6.0.1 → 6.1.0`.

`rust/export/src/usd/tests.rs` demonstrates only ONE of the two breaks. Its
whole diff in #3210 is `+ material_id: None,` inside a `MeshData` struct
literal. The arity break is demonstrated by `rust/processing/src/element.rs`,
whose call went from `with_style_metadata(material_name, geometry_item_id)` to
`with_style_metadata(material_name, source_id, id_is_material)`. Both are now
named, each against the file that shows it.

The "two arguments to three" claim itself is CORRECT and is kept, restated as
the two signatures so it cannot be misread as counting `self`: CodeRabbit
asked for it to be removed as false (#3227), and the diff of
`rust/processing/src/types/mesh.rs` in 50895fb says otherwise.

No behaviour change; changeset prose only.

* docs(changeset): the "nothing gates this" claim is no longer true

The last sentence of the BREAKING paragraph read "Nothing gates this: there is
no `cargo-semver-checks` anywhere in the repo." That was accurate when the
paragraph was written and stopped being accurate at 08:15 today, when #3298
merged `scripts/check-rust-semver.mjs` and its `Rust crate semver` lane; #3305
then added `rust-major-offset.json` at 14:56. `cargo-semver-checks` now appears
27 times across `.github/workflows/` and `scripts/` on main, so the sentence
asserts the absence of something the reader can grep and find.

Shipping it would put a false claim in the published changelog, in the one
paragraph whose entire job is to be accurate about a break the changeset format
cannot express -- and this PR exists only to make that paragraph accurate.

Replaced with what the gate actually does, checked against the source rather
than the PR description: it compares the required bump with the bump the
derived version carries over the crate's latest crates.io release and fails on
the smaller, its documented lint set covers BOTH breaks this paragraph names
(a field added to a `pub` struct callers construct literally, and a changed
argument count), it runs on PRs and again before publish, and the remedy for a
Rust-only major is the committed offset.

The two claims this PR does add both verify and are untouched:
`with_style_metadata(self, material_name, source_id, id_is_material)` is the
live signature at `rust/processing/src/types/mesh.rs:268`, three
caller-supplied arguments; and 6.0.1 is the highest npm workspace version, so
`6.0.1 -> 6.1.0` is the bump a `minor` here derives.

Refs #3227

Author: BIMvoice

.changeset/rep-item-identity-across-boundary.md

@@ -17,4 +17,4 @@ Neither field is ever `0`. `IfcMaterialLayer.Material` is optional, so an air ga
 
 Both fields cross the boundary, both wasm converters carry them, the REST wire shape and `convertServerMesh` carry them, and the cache format gains them at v14 — without that, a cache-restored session silently lost the identity.
 
-BREAKING FOR THE RUST CRATE, and this changeset cannot express it. `ifc-lite-processing` is published to crates.io (`scripts/release-crates.mjs`), `MeshData` gains a public field, and `with_style_metadata` goes from two arguments to three — both break a struct literal or a call downstream, which `rust/export/src/usd/tests.rs` demonstrates in-repo. `scripts/sync-versions.js` derives the Cargo workspace version from the highest npm package version, so a `minor` here ships 6.0.0 → 6.1.0 and a consumer pinned to `ifc-lite-processing = "6"` breaks on `cargo update`. Nothing gates this: there is no `cargo-semver-checks` anywhere in the repo.
+BREAKING FOR THE RUST CRATE, and this changeset cannot express it. `ifc-lite-processing` is published to crates.io (`scripts/release-crates.mjs`), `MeshData` gains a public field, and `with_style_metadata(self, material_name, geometry_item_id)` becomes `with_style_metadata(self, material_name, source_id, id_is_material)` — two caller-supplied arguments to three. Both break downstream, and both are demonstrated in-repo: the added field broke the `MeshData` struct literal in `rust/export/src/usd/tests.rs`, and the new argument broke the call in `rust/processing/src/element.rs`. `scripts/sync-versions.js` derives the Cargo workspace version from the highest npm package version, so a `minor` here ships 6.0.1 → 6.1.0 and a consumer pinned to `ifc-lite-processing = "6"` breaks on `cargo update`. This was ungated when the paragraph was written and is not any more. `scripts/check-rust-semver.mjs` (#3216) asks `cargo-semver-checks` what bump each crate's API change requires, compares it with the bump the derived version actually carries over the crate's latest crates.io release, and fails when the version is the smaller of the two — and its lint set recognises BOTH breaks named above, a field added to a `pub` struct that callers construct literally and a changed argument count. It runs as the `Rust crate semver` lane on PRs and again before the crates.io publish. The remedy it leaves for a break like this one is `rust-major-offset.json`, which advances the Rust major without inventing an npm major.