[Bug][KV] Same-generation reconcile repeatedly restarts in-flight segment registration and blocks startup

[noob512]

Problem Overview

The master reconciles member state every two seconds.

When an owner registers a large segment and the registration RPC takes longer
than one reconcile cycle, a same-generation reconcile schedules another
registration attempt and replaces the unfinished in-flight request.

As a result, the registration RPC never completes, and the master cannot create
the segment allocator for the owner. Allocator readiness remains at 0/512,
blocking the startup process.

Impact

Owner startup may be affected when segment registration takes longer than the
two-second reconcile cycle.

The issue was observed while registering a 256 GiB owner segment.

The RPC only registers metadata such as the segment address and length. It does
not transfer the complete 256 GiB segment as the RPC payload.

Reproduction Steps

1. Start the master.
2. Start an owner configured with a 256 GiB segment.
3. Allow the segment registration RPC to take longer than two seconds.
4. Wait for the master to perform its periodic reconcile.
5. Observe that the same owner generation triggers another registration
   attempt.
6. Observe that the unfinished registration is repeatedly replaced and
   allocator readiness remains at 0/512.

Expected Behavior

For the same owner generation, the master must keep at most one segment
registration request in flight.

A same-generation reconcile should reuse the existing in-flight registration
and allow it to continue until completion.

A new registration should be started only when one of the following conditions
is met:

• The previous registration completed with a retryable error.
• The authoritative owner generation changed.

Actual Behavior

Each same-generation reconcile may schedule an immediate retry.

The retry replaces the unfinished registration future. If registration takes
longer than one reconcile cycle, the request can never complete.

Root Cause

The segment registration actor tracks the desired generation and the registered
generation. However, while the current request is still running, a
same-generation presence/update event is treated as a new registration request.

The following sequence repeats indefinitely:

1. Generation G starts a segment registration RPC.
2. The RPC is still in flight after two seconds.
3. Reconcile sends another presence/update for generation G.
4. The actor schedules an immediate retry.
5. The retry replaces and cancels the unfinished registration future.
6. The allocator for generation G is never created.

Required Invariants

The segment registration actor must maintain the following
generation-scoped invariants:

• If generation G already has a pending registration or retry, another
  presence/update for G must reuse the existing work.
• If the authoritative generation changes from G to G+1, pending work for
  G must be discarded and exactly one registration for G+1 must be started.
• Completion from an obsolete generation must not publish registration state
  for the current generation.

Proposed Fix

Store the owner generation together with the in-flight registration future.

When handling a presence/update event:

• Return without changing state if the same generation already has a pending
  registration or retry.
• Preserve the current in-flight future for the same generation.
• Clear the old future and restart registration only when the generation
  changes.
• Preserve the existing retry and backoff behavior for actual RPC failures.

Acceptance Criteria

• A registration request spanning multiple reconcile cycles can complete.
• Repeated same-generation events do not increase the number of registration
  RPCs started.
• When the generation changes, the old request is replaced and exactly one
  registration is started for the new generation.
• A registration result from an obsolete generation cannot mark a newer
  generation as registered.
• Allocator readiness can continue to progress after a slow registration
  completes.
• Deterministic regression tests cover both same-generation and
  generation-change scenarios.
• Regression tests do not use fixed sleeps as the correctness condition.

Verification Status

• Targeted Rust unit tests for the segment registration state transition have
  passed.
• An isolated release build is being performed using the previously frozen
  r131/r132 Rust source snapshot to prevent unrelated unverified working-tree
  changes from entering the experiment.
• The first release build was affected by a nofile limit of 1024.
• After increasing nofile to 65536, the isolated build continued normally.

Scope

This issue covers the master-side segment registration lifecycle.

The file-descriptor limit encountered during the release build is recorded as
verification context. It does not change the segment registration contract and
is not part of the runtime code change.