Function native_import_payload 

pub fn native_import_payload(
    feature_name: &str,
    solids: &[BrepSolid],
) -> Result<String, String>

Encode solids as a native IMPORT3D payload: stamp the names this feature would stamp under feature_name, then seal them into the io/snapshot container. The result is exactly what the nativeBrep source above reads back, so a part is named identically however it arrived — imported live from a text source, or restored from a payload built here.

GENERIC, not STEP-specific: any producer of finished BrepSolids that wants them to become an IMPORT3D part document uses this (the STEP-assembly import lane is the first caller — kernel-plan step-assembly-import.md §3.1/§3.2).

The two passes after the stamping are register_added’s name-FINALIZING half ([common::ensure_unique_face_names] + [common::stamp_derived_edge_names]), applied HERE rather than at restore time: the nativeBrep lane registers verbatim, so whatever the payload carries IS the final name set. Without them a payload’s edge names would be the importer’s raw ones while the stepText lane’s are the derived {faceA}|{faceB}[n] — the same geometry under two different name sets, which is exactly what this helper exists to prevent.

The payload is byte-deterministic for identical input (snapshot_solids), so two encodings of the same part collapse to ONE parts-library entry.