Fix ReplaceConstantWithAnotherConstant leaving stale import when replacing enum constants

[MBoegers]

Summary

ReplaceConstantWithAnotherConstant correctly rewrote the constant reference (e.g. OldValue.A → NewValue.B) but failed to remove the old import com.constant.OldValue when the replaced constant was an enum constant.

Root Cause

After the visitor modifies the tree, RemoveImport re-scans it via TypesInUse to determine whether the old type is still referenced. For regular static constants (e.g. File.pathSeparator), the J.FieldAccess expression type and the name identifier type are the field's value type (e.g. String) — unrelated to the owning class — so no stale reference remains after the target identifier is rewritten.

For enum constants (e.g. OldValue.A), the expression type is the enum type itself. Two LST nodes were left carrying com.constant.OldValue after replacement:

1. J.Identifier (the constant name A/B) — its .type is the enum type
2. J.FieldAccess — its expression .type is also the enum type

TypesInUse picked these up and RemoveImport concluded the old type was still in use, keeping the stale import.

Fix

After computing the new target, update name.type and fieldAccess.type when they reference the old owning type. Both updates are guarded by TypeUtils.isOfClassType so they only fire for the enum-constant case; for regular constants (where those types are unrelated to the owner), the checks are no-ops.

The duplicate name assignment that existed in both if/else branches was also hoisted out, and the redundant instanceof JavaType.FullyQualified guard before isOfClassType (which performs that check internally) was removed.

Test plan

• New replaceEnumConstant test covers the broken scenario end-to-end
• All existing ReplaceConstantWithAnotherConstantTest tests continue to pass

[timtebeek]

Nice find, thanks!