Read spring.config.location instead of a property that does not exist

[JoseWalker]

ConfigurationManager resolves the config file it writes to from the Spring property
spring.allConfig.location:

this.configPath = resolveConfigPath(environment.getProperty("spring.allConfig.location"));

That property does not exist. Nothing in the repository sets it, and it is not a Spring Boot
property, so getProperty always returns null and resolveConfigPath always takes its
hardcoded fallback branch. The effect is that the entire resolveConfigPath logic below the
null check — directory handling, the file: prefix strip, the comma-separated list handling —
is unreachable in practice.

This changes the lookup to spring.config.location, which is what the surrounding code is
clearly written for: stripping a file: prefix and taking the first entry of a comma-separated
list only makes sense for Boot's own config-location property.

Tests

ConfigurationManager had no test coverage. This adds ConfigurationManagerTest (9 tests)
covering the resolution rules and the write path:

• location pointing at a file, and at a directory
• file: prefix stripped
• first entry taken from a comma-separated list
• writes land in the configured location
• nested keys are written without discarding siblings
• updateProperties writes once and publishes one ConfigurationChangedEvent
• a missing config file yields an empty map (first-run onboarding)

The assertions key off a marker value that only exists in the test's @TempDir. That detail
matters: an earlier draft of these tests asserted on an agent: key and passed before the
fix, because with the typo in place the manager resolves the fallback path and reads the
repository's own application.private.yaml. Pinning to a unique marker makes the tests fail
without the fix, which they now do (8 of 9 red before, all green after).

Scope, and two things left out on purpose

Deliberately limited to the property name.

While writing the tests I ran into a related but separate problem: the location this manager
writes to and the location Boot reads private config from are not the same, so onboarding
does not persist in a packaged jar or in the Docker image. That is a design question rather
than a typo, so I am filing it as its own issue rather than growing this PR.

Making the property live for the first time also exposes two pre-existing gaps in
resolveConfigPath, which this PR does not touch. Flagging them so they are a known choice
rather than a surprise:

• a classpath: location is not handled — only file: is stripped, so Path.of("classpath:/…")
  becomes a literal path that will not exist, and readApplicationYaml then quietly returns an
  empty map;
• candidate.replace("file:", "") replaces every occurrence rather than a leading prefix.

Happy to fix either here or in a follow-up, whichever you prefer.

Verified with ./gradlew test (128 tests, 0 failures) and the Modulith / ArchUnit gates.

[arefbehboudi]

Thank you @JoseWalker. Great job!