Cluster runtime retains targets while waiting for a lease

[pood1e]

Bug

In a clustered subscribe deployment, GET /api/v1/targets can retain the same target on two members after a lease changes owner. The lease has one holder, but a member waiting to acquire it inserts the target into its runtime map before Lock returns. If another member keeps the lease, that pending entry can remain indefinitely. A lease-loss retry can create another pending entry through the same path.

Impact

Runtime target counts and membership checks report duplicates even though the lease limits active subscription ownership. Pending goroutines and target objects may also remain until the lease becomes available or the process restarts.

Expected behavior

A lock attempt should have a finite deadline. Failed or canceled attempts and completed lock sessions should remove their runtime target generation. Periodic assignment reconciliation can retry when ownership changes.

This is separate from the loader snapshot deletion case in #1023.

[pood1e]

A fixed 10-second lock deadline would be unsafe when a configured lease lasts that long or longer: the contender may cancel before takeover is possible. The deadline should include the locker's lease duration and retry margin. While acquisition is pending, the runtime API should only expose targets whose lock was actually acquired. Failed or canceled attempts still need generation-safe cleanup.