Refresh drops @ConfigurationProperties values that no property source carries

[guerricm]

Since spring-cloud-context 5.0.2, ConfigurationPropertiesRebinder resets every rebindable bean to
the defaults of a template instance before re-binding it. Whatever was set programmatically after
the initial binding is gone, because the re-binding only restores what the Environment carries.

Java 25, Spring Boot 4.1.1, Spring Cloud 2025.1.3, spring-cloud-context 5.0.3,
spring-cloud-netflix-eureka-client 5.0.2.

Sample, three Initializr projects, the application under test has no code of its own:
https://github.com/guerricm/bug-refresh

POST /actuator/refresh answers [], so no key of the Environment changed. eureka.instance
changes anyway:

BEFORE                                      AFTER
hostname      : localhost                   hostname      : localhost
ipAddress     : 192.168.1.117               ipAddress     : null
metadataMap   : {management.port=8080}      metadataMap   : {}
nonSecurePort : 8080                        nonSecurePort : 80

An empty change set is not a condition of the bug, only the shortest proof that the refresh itself
drives the reset. hostname survives because application.yaml carries it.

The Eureka instance is then cancelled from the registry and cannot register again:
ApplicationResource.addInstance answers 400 Missing ip address for a blank ipAddr. The
application keeps running and is simply absent from the registry.

resetBeanToDefaults builds its template through any no-arg constructor, whatever its visibility.
EurekaInstanceConfigBean declares a private EurekaInstanceConfigBean() {} next to the public
EurekaInstanceConfigBean(InetUtils) that computes ipAddress and hostname, so the template
carries ipAddress = null, nonSecurePort = 80 and an empty metadataMap. The re-binding restores
none of the three: they come from the public constructor, from EurekaAutoServiceRegistration, and
from EurekaClientAutoConfiguration:204.

Absent in 5.0.1, introduced in 5.0.2 by #1680, extended in 5.0.3. The sample carries a
-Pcontext-5.0.1 profile that downgrades that artifact alone; the same refresh then leaves the bean
untouched. #1680 targets a property removed from the Environment while the bean keeps its value,
and the reset cannot tell that apart from a value that was never in the Environment.

Related: #1727, same pull request, nested objects passing through null during the rebind. That one
is transient and traffic dependent; this one is the state the bean is left in, on an idle
application.