feat(ui, nodes): add fields for CLIPEmbedModel and FluxVAEModel

[maryhipp]

Summary

• update flux model node to take inputs for CLIP Embed and VAE - this removes the brittle way in which they were hard-coded, which will hopefully make it easier for users to upload and use models that were not directly downloaded from our starter model list
• update default FLUX workflow to have these fields. this will improve validation in the front-end when a user is missing a model; they will not be able to Invoke and hopefully more easily figure out why.
• I had to re-download my Flux VAE while working on this but am not sure if it was related to my changes. The error was around the config_path so I may have had an out of date install in my DB.

Related Issues / Discussions

QA Instructions

Restart server (make sure that DB has this default workflow loaded) and run workflow. Should be required to make a selection from your installed models for all four models for the Flux model node.

Merge Plan

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• Documentation added / updated (if applicable)

[brandonrising]

lgtm, the flux main and vae components we've added recently make me wonder if there's a way to add fields like this without creating entire components when the Model config type they're managing don't change.

As in it'd be nice if we could have re-used the VAEModelFieldInputComponent, but just pass in the isFluxVAEModelConfig filter somehow since they both manage a VAEModelConfig. Def not something to worry about in this PR though.

[psychedelicious]

lgtm, the flux main and vae components we've added recently make me wonder if there's a way to add fields like this without creating entire components when the Model config type they're managing don't change.

It's certainly possible to abstract it further but I don't know if that is valuable:

• We add stateful model fields infrequently
• There are subtle differences between some of them that would require the abstractions would to be overly flexible
• These are simple components with a clear pattern
• There are already some abstractions (via hooks) that hide away the bulk of the complexity; we wouldn't be saving much code