fix: let a navigation-result collector take over a key from a cancelled holder

[PavelMesicek]

Fixes #199.

NavigationResultRegistry.results() used a Set<String> to fail fast on duplicate collectors, released in the collecting flow's finally. When a destination is recreated in place (bringToFront with a reseeded configuration), Decompose creates the replacement child before destroying the outgoing one, and both the successor's attach and the outgoing collector's cancellation cleanup go through the main queue in that order. The successor therefore found the key still held and the check threw out of a bare launchIn, killing the process. The issue has the full trace.

This PR keeps the fail-fast contract but makes it precise about what "active" means: the registry now tracks the holder's Job per key, and a new collector may take the key over when the holder is no longer active. Job.cancel() flips isActive synchronously, so the successor attached on the same tick sees the outgoing collector as gone even though its finally has not been dispatched yet. A genuinely live holder still fails the check exactly as before. The finally release is guarded so a collector that was taken over cannot remove its successor's registration.

Nothing changes about delivery semantics: the pending durable value is consumed only after the check, so a handover loses no result, and the existing duplicate-collector test still passes unchanged.

The new test replays the create-before-destroy ordering against the real registry: it fails on main with the IllegalStateException from the check and passes with this change. Ran :decompose:allTests and ktlintCheck, both green.

🤖 Generated with Claude Code