Fix(backend & frontend): Present Flux.2 reference images in the same order as shown in the frontend

[lstein]

Summary

The Flux.2 klein models allow you to pass multiple reference images and refer to them explicitly as "image 1", "image 2", etc. However, the CollectInvocation items were being sorted by (iteration_path, source_node_id) when building collections. This has no relationship to the left to right visual order in which the images are displayed in the front end. As a result, referring to "image 1" in the prompt would not always correspond to the leftmost image.

This PR fixes the problem by sorting the collection by its input_edges index, which corresponds to the left to right ordering of the images visually. As an added bonus, I've added a drag-and-drop function that lets you change the order of the reference images on the front end.

Related Issues / Discussions

QA Instructions

1. Use Flux.2 Klein 4B or 9B
2. Drag three distinctive images into the Reference Image area
3. Give a prompt like "Paste the three images into three distinct panels from left to right"
4. Use drag and drop to change the order of the images
5. Repeat the prompt

You should see that the generated image more-or-less follows the visual order of the images. However, it appears that the model pays more attention to the first image and progressively less to subsequent ones, so in general the leftmost part of the generated image will correspond well to image 1 and the other two panels will suffer semantic leakage.

You can also try prompts like "The subject of image 1 is shaking hands with the subject of image 2."

Merge Plan

Simple merge

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[JPPhoto]

Instead of doing it this way, why not make a "linked" version of the collect node that allows for chaining? An image collection linked node already exists in https://github.com/skunkworxdark/collection_tools.

[lstein]

Instead of doing it this way, why not make a "linked" version of the collect node that allows for chaining? An image collection linked node already exists in https://github.com/skunkworxdark/collection_tools.

@JPPhoto Are you suggesting I copy Skunkworx's linked node code into the main repo? Will this cause any conflicts or confusion?

[JPPhoto]

@JPPhoto Are you suggesting I copy Skunkworx's linked node code into the main repo? Will this cause any conflicts or confusion?

I think all of the linked nodes are great, I use them all of the time, and they enforce ordering. So (with permission) I think they should all be in the main repo, then the frontend could chain them in the graph builder to create proper ordering.