feat: place members with a rigid rotation and edit their orientation - #243

PR #243 - rigid member placement rotation - CHANGES REQUESTED

Two required changes, both inline; the feature itself is solid.

1. A plate can be committed with a rotation its readers refuse. patch_plate applies orientation_xyzw, the CLI writes the placement attribute and the revision publishes with exit 0 (the plate branch re-evaluates nothing: the body-rebuild condition orientation && member skips plates, and there is no post-commit re-evaluation in update_element). But every read path of a committed plate with a non-identity quaternion refuses: scene_elements_with_members raises UNSUPPORTED_GEOMETRY, and plate-inspect builds that scene too, so the store stops inspecting, snapshotting, exporting and picking until someone patches the rotation back. The write path must not admit a state the read paths reject: refuse a non-identity orientation patch for a plate in patch_plate (UNSUPPORTED_GEOMETRY, mirroring create_plate), keep the identity accepted as the documented reset, update the update.rs unit test that currently pins the accepting behaviour, and align the model doc comment that promises the patch for a member or plate.

2. The new image dependency is used by nothing. Nothing under apps/beamcraft-ui references the crate; the icon PNG path still goes through eframe::icon_data::from_png_bytes in theme.rs, unchanged from master. Drop the dependency and its Cargo.lock entry.

What I checked and found sound:

• The composed frame is right and pinned by hand-derived expectations: R_placement . (axis x up/roll), roll about the member axis first; the integration test derives the vertex map independently of the engine helper.
• rotate_vector is the standard unit-quaternion rotation, normalized before use, and every caller reaches it through a validated (nonzero-norm) quaternion.
• Identity keeps the mesh bytes (cached bodies and stored digests stay stable); q and -q land on the same bytes; quantities, axis length and section area stay invariant - all asserted.
• The member cache key gains the quaternion (a shape input) while the translation stays out; scene elements become translation-only for both kinds, consistently.
• The content fingerprint appends the quaternion bytes only when the patch names one, so earlier fingerprints are unchanged.
• Bonus fix worth noting: Placement::validate now catches non-finite quaternions; previously NaN slipped through the norm check and validated.
• Footprint wiring: an orientation change reads and writes the placement group plus the derived group, the member body rebuild lands in the derived group; check_footprint sees the declared set.
• The ghost preview is display-only, defensively indexed, drawn on its own pipeline with a distinct fragment, and the ground-plane fallback rejects points beyond the coordinate cap.
• The default-workspace bootstrap races are handled honestly: definition_exists is an outcome rather than a refusal, and DUPLICATE_ID is tolerated on the fork.
• Help text and README document the new flags, including none on update; the CLI integration tests cover set, clear, replay and hostile input.

Optional, body only: the default-workspace helpers and the axis-format test ride along in a rotation PR; the body discloses the former, and both are harmless, but a follow-up that moves them would keep slices tight.

PR #243 - rigid member placement rotation (round 2) - APPROVED

Both required changes from the previous review are in and correct:

• patch_plate now refuses a non-identity orientation_xyzw with UNSUPPORTED_GEOMETRY and the create-time message, before placement_after, so a committed plate can no longer carry a rotation its readers refuse; the identity still resets the pose. The unit tests were rewritten to pin the refusal, the identity reset, and the new refusal order (the engine guard fires before the model-level code checks, mirroring create_plate).
• The unused image dependency is gone from apps/beamcraft-ui/Cargo.toml and Cargo.lock.
• The model doc comment now states the plate refusal instead of promising the patch for a member or plate.

No further change requested. One optional asymmetry, body only: the new guard compares bytes against [0,0,0,1], while is_identity_rotation treats any x = y = z = 0 quaternion (so w = -1 too) as the identity, and create_plate accepts that. A plate patch of [0,0,0,-1] is therefore refused where the same rotation is accepted at creation. It is an over-strict refusal of an exotic input, nothing is corrupted, so this can ride - reusing the placement is_identity_rotation check instead of the byte comparison would align the two paths.

The rest of the feature was reviewed in the previous round and is unchanged here (the fix commit touches only the four files above).