Fix #2579: keep blender_idxs in sync with dots_edges dedup

[Builder106]

Problem

Exporting a custom float attribute on loose edges could produce mangled geometry: each exported vertex's position and its attribute value could end up belonging to two different original Blender vertices.

@julienduroure traced the first-order cause to fast_structured_np_unique vs np.unique behaving differently. @Mysteryem dug further and found the actual mismatch: in primitive_creation_edges_and_points, self.blender_idxs was computed via a standalone np.unique(self.blender_idxs_edges) call, independent of the fast_structured_np_unique(self.dots_edges, ...) dedup used for the attribute data itself, unlike the matching pattern in primitive_creation_shared/primitive_creation_not_shared.

Since __set_positions_attribute builds POSITION from self.locs[self.blender_idxs], while other attributes are read straight off dots_edges, the two independently-sorted arrays don't share row order, so position and attribute data get paired up incorrectly.

Solution

Derive self.blender_idxs from the same deduplicated self.dots_edges used for the attribute data, matching the existing pattern in the two sibling functions, per @Mysteryem's proposed fix in the issue thread.

Verification

• Isolated test against the real fast_structured_np_unique: 11/12 row mismatches with the old logic, 0/12 after the fix.
• Full export against the reporter's attached repro file on Blender 5.1.1: exports cleanly, exact expected vertex count (835/835), both POSITION and the custom attribute present and correctly paired.

Closes #2579