Continuing the score and flow matching sampler improvements (azula interface and vector field adaptor init)

[SahilKumar75]

I have been working in the score and flow matching sampler code and would like to help continue the improvements started under the now closed umbrella issue #1435. Before opening any PRs I want to check direction with the maintainers, since two earlier attempts in this area were closed without merging and I do not want to repeat designs that were already turned down.

Two open, unassigned issues stand out to me:

1. Interface to azula samplers (Adding interface to azula samplers #1468). sbi currently builds a Diffuser from a potential function, a predictor and a corrector, while azula bundles predictor and corrector combinations per sampler. The issue proposes either wrapping azula samplers as Predictor classes or writing an AzulaDiffuser subclass of the base Diffuser. A benchmark PR (Benchmark: azula sampler comparison on two_moons #1825) was opened and then closed without merging.

2. Vector field adaptor initialization without caching (Improve vector field adaptors to not require caching #1783). The one time hyperparameter fitting needed by post hoc adaptors (iid data, prior guidance) is currently hidden behind caching on the first call, which makes execution order matter and ties correctness to cache state. The issue proposes a dedicated init or fit step before sampling and a cleaner API such as posterior.with_iid(...).sample. Two refactor PRs (Refactor vector field potentials: add init() setup and PosteriorBuilder #1802 and Add explicit init() to BasePotential and NeuralPosterior #1829) were opened and closed without merging.

As an entry point I am about to file a small separate bug fix for the Langevin corrector, which evaluates the score at the next diffusion time instead of the current one, so I am already working in this part of the code.

What I would like feedback on:

1. Which of the two issues is the higher priority for the maintainers right now.
2. For Adding interface to azula samplers #1468, do you prefer the Predictor wrapper or the AzulaDiffuser subclass, and should azula be an optional dependency.
3. For Improve vector field adaptors to not require caching #1783, what led to Refactor vector field potentials: add init() setup and PosteriorBuilder #1802 and Add explicit init() to BasePotential and NeuralPosterior #1829 being closed, and what shape of the init or fit API would be acceptable so that a new attempt does not run into the same problems.
4. Whether this work is better scoped as one larger coordinated effort or as several smaller independent PRs.

If an enhancement proposal is the preferred path for the API changes in #1783, I am happy to write one up.