fix: deliver the fork delta of the 1113 sync wave - #875

Closes #558

A committed A14.3 bolt group went out of `export-ifc` as an
IfcBuildingElementProxy with no representation: the proxy path reads the
element's own published mesh, and a bolt group's prim carries none - its
fastener geometry was built only for the view snapshot. Every exported
file therefore showed an empty element where the bolts and the washers
should be, which is the "Болтов нет, шайб нет" of the issue.

`bolt_scene::scene_element` now returns the merged solid beside the scene
element (same vertices, digest and volume; one caller), and the decode
step publishes it as the group's ElementMeta mesh through the existing
kernel_mesh + published_mesh path. The export's proxy branch then carries
the fasteners unchanged, exactly the mesh a view draws. A weld keeps its
path solid, and an element whose prototype is refused still refuses the
inspection instead of exporting bolts without their hardware.

The new CLI test exports a committed group and reads the proxy's face set
back out of the file: two SYN-BOLT-12x50 stacks, well over a hundred
vertices.

Reproduced on fresh origin/master before the change: the group row had
`representation: null` and the written file carried no fastener face set;
after the change the same store exports the mesh (816 points, 1608
triangles, no degenerate triangle).

Co-authored-by: axisrow <[email protected]>

The scanner kept only IfcSIUnit, IfcProject, IfcUnitAssignment and
IfcConversionBasedUnit as resolvable instances, but the units assignment may
reference every member of the IfcUnit select type. A file written by
export-ifc lists an IfcDerivedUnit (mass density) in the assignment, so the
scan reported DANGLING_UNIT_REFERENCE for an instance it counted in its own
inventory: every export-ifc file looked damaged to ifc-inspect.

Add IfcDerivedUnit and IfcContextDependentUnit to the lookup so it covers the
whole select type; both cannot change the length unit and are no loss, like
the conversion-based one. A roundtrip test scans a written file and expects
zero losses.

Co-authored-by: axisrow <[email protected]>

…export-ifc (#601)

The exporter read the hole count from the deprecated create-authored
holes_mm attribute, so a plate whose holes all came from AddHole looked
hole-free: the file said HoleCount 0 and carried GrossVolume and
GrossWeight equal to the net ones, against IFCX-QTY-004, while the mesh
held the hole. Read the count from the evaluated body, the same source
the mesh and the model's hole_count use, so gross quantities follow the
operations the geometry actually has (issue 598).

Co-authored-by: axisrow <[email protected]>

…599)

The forbidden-substring list in the_report_file_equals_the_printed_report
carried a bare "tmp" entry. IFC GlobalIds are 22-character base64 strings
(alphabet 0-9A-Za-z_$), so with roughly 1-in-2000 probability a random
GlobalId contains the literal substring "tmp" and the assertion tripped
although no path had leaked. The fixture-root entry already covers real
path leakage from the test's own temp tree; anchor the remaining temp-path
guard as "/tmp/", which cannot occur inside a GlobalId.

Co-authored-by: axisrow <[email protected]>

…603)

* Read placed IFC bodies: the ifc-shapes command and the shapes reader

The MVP IFC input workflows needed the geometry half of the E04 input
slice: ifc-inspect inventories the bytes, but nothing read the placed
shapes back.

beamcraft_ifc::shapes reads every product whose representation resolves
to an IfcProductDefinitionShape over IfcTriangulatedFaceSet items,
resolves the IfcLocalPlacement chains and the declared length unit, and
returns the placed bodies in millimetres with an explicit loss list and
bounded budgets. The new ifc-shapes command reports the same facts
headlessly over one JSON reply: the source digest and size, the declared
schema, the unit, product and shape counts, per-body identity, vertex
and triangle counts, placed bounds and the losses.

The committed fixture tests/fixtures/ifc/plate-hole.ifc pins the exact
facts of the holed plate of the display issue, and the writer round trip
asserts them against a fresh export-ifc output. This is the foundation
slice; the display of the read bodies follows in the next slice.

* Refuse a face set that declares its own Unit

Review finding: read_face_set ignored the IfcTriangulatedFaceSet Unit
attribute, so a body declared with a per-body unit silently took the
project scale and left mis-scaled with no loss. A declared unit is not
interpreted here, so the body is now refused with a
FACE_SET_UNIT_NOT_READ loss; $ (the writer's own form) keeps reading.

---------

Co-authored-by: axisrow <[email protected]>

)

The face-on section test's plane sat at the bounds-centre height plus 5 mm,
but `origin_mm` is the bounds centre, so the plane passed 2 mm above the
6 mm plate and kept the whole body: the cut frame was byte-identical to the
uncut one and the assertion repeated the uncut frame's own check. The plane
now runs through the scene's mid-height as the test's own description always
said (the kept half's opened inside, the crossing section outline), and the
assertion counts the kept body's lit pixels plus the section outline ink.

On the Dx12 software rasterizer (Microsoft Basic Render Driver, windows-2022
platform shards) this also stops the test from tripping a rasterizer fault:
with any cut uniform active in a steep view, the software rasterizer draws a
fragment invocation of one primitive with another primitive's interpolated
inputs, which erased the lit kept body exactly here. The section ink is drawn
through the vertex-stage face-on cap, which the rasterizer handles correctly,
so the section stays visible there.

Co-authored-by: axisrow <[email protected]>

…r recheck (#606)

* fix: close the partial items and new defects of the #562 recheck

The recheck of #562 on master found four items only partly fixed and a handful of new
visible defects. This closes them:

- Item 8: a detail callout name now steps off any drawn stroke, so the parent's body edge no
  longer strikes through "DET B".
- Item 15: a selected bolt group is named (the bolt listing is read when it was never loaded)
  and offers no Apply/Reset, since it has nothing to edit.
- Item 47: at 800x600 the snap strip shows chevrons that say and scroll what is cut off, and a
  short window drops the Menu heading so Help no longer hides under the footer.
- Item 52: a colour set picked but not shown yet gets a note naming whose legend is shown.
- New: a drawn text the stroke glyphs cannot draw refuses at edit-drafting instead of leaving
  a published version that can never be exported.
- New: finishing a plate (and any window-run edit) keeps the camera; a kept camera now follows
  the scene's new origin instead of jumping aside.
- New: Visibility/Graphics and other floating windows open and stay between the ribbon and
  the status bar.
- New: the status line says "Updating the view..." while an edit's refresh is still loading.
- New: small report quantities keep four significant digits instead of every float digit.
- New: the start window's environment list stays inside the window and its note describes
  Blank only when Blank is chosen; an empty model's thumbnail shows a framed placeholder.

Refs #562

Claude-Session: https://claude.ai/code/session_01HF6nmWCNmnwESuVYDnreeF

* fix: seat bolt nuts on the joint and close the rest of the #562 master recheck

The recheck of #562 on master found two items still visible and two small new defects:

- Item 5: the nut stack hung from the thread tip, so any listed length longer than the
  joint needs floated the nut washer 2-6 mm off the far plate on bare shank. The drawn
  group now measures each fastener's far face with the placement's own bearing-ring rays
  (engine::bolt::far_faces) and seats the nut stack there; the surplus shows as
  protrusion. A joint that cannot be measured (a framed plate) keeps the tip-hung stack,
  so a read never refuses for it.
- Item 54: the full-name tooltip of the environment list ran past the 460 px start
  window; it now wraps inside it.
- The ribbon overflow chevron was only painted: a click pressed the half-hidden tool
  under it and it stayed after scrolling to the end. It is now a button on its own strip
  that scrolls the ribbon, shows only while there is more on its side, and the plain
  wheel scrolls the ribbon.
- The undo/redo sentence vanished the moment the window re-read the selection after the
  edit. That re-read now keeps the edit's outcome and shows no "Looking up...".

Refs #562

Claude-Session: https://claude.ai/code/session_01HF6nmWCNmnwESuVYDnreeF

---------

Co-authored-by: Claude <[email protected]>

…urce (#605)

The display half of the IFC reading slice. The shapes reader (ifc-shapes)
reads the placed bodies of a received file but had no consumer, so
BeamCraft could not show even its own export-ifc output.

export-view --source builds the engine's view bundle from a received
file: every read body becomes one reference-kind display element through
the new engine::scene::foreign_display_element (the kernel TriMesh
rules), and the snapshot is pinned to the file's own SHA-256, so the same
bytes give the same bundle and from_bundle re-validates it exactly like a
store snapshot. The framed store extras are refused: a source file is one
read-only display, not a revision.

screenshot-view --source relays the file to beamcraft-ui, which exports
the bundle from the CLI process and renders it with its own renderer; no
store is opened anywhere on the path. --store given a file now refuses
with "a file and not a store" instead of a bare integrity error. The
end-to-end test renders the 120 x 80 x 10 plate with its 18 mm hole at
(60, 40) and asserts that the background shows through the hole.

The view export family help and COMMANDS.md document the one-of source
form and what a received file does and does not carry: no store, no grids
or annotations, catalogue colours only, bundle pinned to the file digest.

Refs #596.

Co-authored-by: axisrow <[email protected]>