Programmatic GenericFilter prompts for a configuration name when opened for editing #5451

[fractal3000]

Fixes #5451

Problem

Opening the configuration editor for a named run-time configuration that exists only in memory (created programmatically, or added via addConfiguration, and never persisted) shows an empty "Configuration name" field and the "Configuration name required" error, even though the name is visible in the filter header. The conditions are transferred correctly; only the name is lost.

Root cause

GenericFilterSupport.loadFilterConfigurationModel(boolean isNewConfiguration, Configuration currentConfiguration) loads the model from the database by id whenever isNewConfiguration is false (i.e. the id is not the empty-configuration id). For an in-memory configuration there is no database row, so the load returns null and the fallback creates an empty FilterConfigurationModel carrying only the username — the name (and id) are not copied. The editor binds to that empty model.

Fix

In the fallback, when the configuration is not new, copy its id and name into the model. The id is required as well: on save, saveCurrentFilterConfiguration builds the result configuration from configurationModel.getConfigurationId(), and initFilterConfiguration replaces the existing configuration when the ids differ — so without the id the save would drop the original and create a broken/duplicate configuration. The isNewConfiguration guard leaves both empty for a genuinely new configuration.

Notes

• Pre-existing editor bug, independent of the programmatic-configuration API (GenericFilter: add convenience API for programmatic filter configuration #5351): it reproduces for any in-memory named run-time configuration not present in the database, regardless of how it was created.
• The persistence path lives in flowui-data, so the regression test lives there too.

Tests

Added GenericFilterConfigurationNamePrefillTest (flowui-data) covering all three branches of loadFilterConfigurationModel(boolean, Configuration):

• Existing in-memory configuration, not in the DB (isNewConfiguration == false, load returns null): the fallback model is pre-filled with the configuration's id and name. This is the fixed case — it fails on the unpatched code (expected: <Open Projects> but was: <null>) and passes with the fix.
• Existing persisted configuration (isNewConfiguration == false, configurationModel != null): the stored model is returned unchanged, the fallback is not entered.
• New configuration (isNewConfiguration == true): the fallback model stays empty (no id/name), so creating a new configuration still asks the user for a name — this guards the !isNewConfiguration guard.

The branch actually taken is asserted via EntityStates.isNew (a model loaded from the database is not new; a metadata.create fallback model is). The existing FilterConfigurationPersistenceTest stays green.