Fix #2412 - drop displaced factory's cached singleton on override

[glasser]

Fixes #2412.

When InstanceRegistry.saveMapping overrides an existing mapping (e.g. via koin.declare(...)), the displaced InstanceFactory was left with its value still cached. Because Module.mappings shares factory references with the registry, the orphan survived stopKoin() (which only iterates _instances) and was re-installed on the next startKoin { modules(sameModule) }, leaking the previous lifecycle's singleton into the new one.

This is a long-standing latent bug — present in every released koin version going back to 3.x. It only manifests when the same Module instance is loaded across multiple stopKoin/startKoin cycles after a declare override has populated the displaced factory's cache. That combination is rare in production but routine in test setups; in particular it became newly visible in late-2024 / 2025 to users of kotest-extensions-koin after kotest 6 turned Spec.extensions from a function into a property. See the issue for the full diagnosis, the kotest-6 connection, and a public reproduction repo.

The fix is two lines in saveMapping's override branch: when _instances[mapping] is being replaced by a different factory, call dropAll() on the displaced one before overwriting. The displaced !== factory guard preserves the no-op behavior when the same factory is re-registered (e.g., loading an already-loaded module).

Test

Adds DeclareOverrideDropsCachedSingleTest covering the regression: declare a fresh override on top of a module-owned single, mutate the singleton, stopKoin, then startKoin with the same module instance — get<T>() must return a fresh singleton.

• Without the patch the test fails on the assertNotSame(first, second) and assertEquals(0, second.value) assertions.
• With the patch the new test passes, and the full :core:koin-core:jvmTest is green (284/284, including all of DeclareInstanceTest — no behavior change for documented declare/override semantics, only for the latent cache leak).