What this PR does / why we need it:

_allocate_and_put() on the decoder side leaks GPU buffer slots when it receives an AllocRequest containing keys that already exist in self.data (e.g., from a previous request with a shared prefix, or a multi-round conversation reusing cached KV).

When contains(key, pin=True) finds an existing key, it increments ref_count from 1 to 2. Nothing on the already_sent_indexes path calls ref_count_down() to undo it. Later, remove() sees ref_count == 2 and skips the delete. ref_count_down() brings it to 1, but nobody calls remove() again — the buffer slot is permanently leaked.

The fix changes contains(key, pin=True) to contains(key, pin=False). Pinning is unnecessary here because PDBackend has no eviction mechanism. Unlike LocalCPUBackend, which evicts existing entries when the buffer is full and uses pin to protect entries being read from concurrent eviction, PDBackend's paged GPU allocator only frees blocks explicitly via remove() after the decode forward pass consumes them. There is no concurrent eviction thread that could remove an entry between the contains() check and the NIXL write completing. The upstream storage_manager already enforces this — pin_in_backend = pin if backend_name != "PDBackend" else False — PDBackend is never pinned on the lookup/retrieve path either.

Special notes for your reviewers:

The ref_count lifecycle on the decoder side is:

1. allocate() creates MemoryObj with ref_count=1
2. put() stores it in self.data
3. get_blocking() returns it (no ref_count change)
4. batched_to_gpu() copies data to vLLM's paged KV buffer
5. remove() checks ref_count == 1 → del self.data[key]
6. ref_count_down() → ref_count 1→0 → triggers parent_allocator.free() → block returns to free_blocks

With pin=True at step (2-repeat), ref_count goes to 2, and step 5 skips the delete, breaking the chain.

How to reproduce:

Use the existing examples/disagg_prefill/1p1d/ setup:

# Start the 1P1D DPD setup (prefiller on GPU 0, decoder on GPU 1)
cd examples/disagg_prefill/1p1d
bash disagg_example_1p1d.sh

Then send multiple requests that share a common prefix (e.g., same system prompt). The key is that different requests produce overlapping chunk keys in the decoder's _allocate_and_put:

# Send requests with shared prefix — repeat 10+ times
for i in $(seq 1 20); do
  curl -s http://localhost:9100/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
      "model": "meta-llama/Llama-3.1-8B-Instruct",
      "prompt": "You are a helpful assistant. Explain the concept of '"request_$i"' in detail.",
      "max_tokens": 256
    }' &
done
wait

Before (pin=True) — decoder log shows:

WARNING ... PDBackend.remove SKIPPED for key ... (ref_count=2)
WARNING ... PDBackend.remove SKIPPED for key ... (ref_count=2)
# After enough requests, allocate() blocks indefinitely — no new completions

After (pin=False) — decoder log is clean:

# No "remove SKIPPED" warnings. Buffer slots freed after each decode completes.
# Requests complete indefinitely.

The leak is cumulative. With a 2GB pd_buffer and 256-token chunks, the buffer exhausts after ~30-50 requests depending on prefix overlap. Once exhausted, all subsequent allocate() calls block and no new requests complete.

If applicable:

• this PR contains user facing changes - docs added
• this PR contains unit tests