Saving properties duplicates a variable that was declared with its legacy name (e.g. MAVEN_VERSION) #2717

Actual behavior

When a properties file declares a variable with its legacy name (e.g. MAVEN_VERSION) and IDEasy saves a change to that variable, the migrated line is written twice.

Cause in EnvironmentVariablesPropertiesFile.save():

• migrateLine(line, true) renames MAVEN_VERSION to MVN_VERSION and applies the new value. This line is written correctly.
• Then this.modifiedVariables.remove(line.getName()) is called with the original (legacy) name MAVEN_VERSION, so MVN_VERSION stays in modifiedVariables.
• The loop "append variables that have been newly added" therefore writes MVN_VERSION=3.9.6 a second time.

On every following run IDEasy logs Duplicate variable definition MVN_VERSION .... This affects all variables with a legacy name, e.g. MAVEN_VERSION, DEVON_IDE_TOOLS, DEVON_CREATE_START_SCRIPTS, so mainly projects migrated from devonfw-ide.

Reproduce

1. Put MAVEN_VERSION=3.8.8 into settings/ide.properties.
2. Run ide set-version mvn 3.9.6.
3. settings/ide.properties now contains MVN_VERSION=3.9.6 twice, and the next ide call warns about a duplicate variable definition.

Verified with a unit test in EnvironmentVariablesPropertiesFileTest on main (41eb889): after set("MVN_VERSION", "3.9.6", false) and save(), the file contains [MVN_VERSION=3.9.6, MVN_VERSION=3.9.6], and reloading it logs Duplicate variable definition.

Expected behavior

The legacy line is migrated in place and the file contains exactly one line MVN_VERSION=3.9.6.

IDEasy status

IDE_ROOT is set to C:/projects
IDE_HOME is set to C:/projects/project
Your version of IDEasy is 2026.10.001-09_29_08-SNAPSHOT.
Your operating system is windows(10.0)@x64 [Windows 11@amd64]
You are online.
Your settings are up-to-date.

Related/Dependent issues

#2537 / #2556 (adds renamed variables in the same file)

Comments/Hints

Suggested fix: use the migrated name in line 211, i.e. String name = newLine.getName();. With this change the test above writes a single line and all existing tests in EnvironmentVariablesPropertiesFileTest still pass.

Please add the reproduction above as a regression test. Open PR #2556 touches the same file and keeps line.getName() at this spot, so its new rename path would run into the same issue.