Fix inaccuracies in RoPE and block hash explanation

[YangooSen]

Clarified the relationship between K vectors and block hashes in the context of vLLM APC.

[grissomsh]

感谢指出，你的理解是对的。我们对照最新 main（8b365ff949）核实了源码。

当前实现（vllm/v1/core/kv_cache_utils.py:650-680）：

def hash_block_tokens(
    hash_function: Callable[[Any], bytes],
    parent_block_hash: BlockHash | None,
    curr_block_token_ids: Sequence[int],
    extra_keys: tuple[Any, ...] | None = None,
) -> BlockHash:
    ...
    if not parent_block_hash:
        parent_block_hash = NONE_HASH

    curr_block_token_ids_tuple = tuple(curr_block_token_ids)
    return BlockHash(
        hash_function((parent_block_hash, curr_block_token_ids_tuple, extra_keys))
    )

哈希输入只有三样：父块哈希、当前块的 token IDs、extra keys（后者仅多模态 / LoRA 请求生成，见 get_request_block_hasher 的调用处）。K 向量、embedding、RoPE 相位都不参与。

所以正文 §1.3 那句「K 向量不同导致 block hash 不同」确实不成立——而且与我们自己在脚注 [^1] 和「hash chaining 隐式编码位置」处的描述相互矛盾。准确的机制是两层：

1. 查找失败的原因：前文 token 序列不同 → 父块哈希不同 → 当前块哈希不同 → 查找失败。位置的影响是经由哈希链间接进入的；
2. RoPE 真正的障碍：哈希一旦命中，前缀必然逐字相同，绝对位置也必然相同。位置"烧进"K 影响的不是查找，而是复用的正确性——缓存若要挪到别的绝对位置复用，必须重新施加位置编码。这正是文中方案 B（nope 哈希 + 重算 RoPE）的出发点。

修改方向建议（供参考）：

1. 直接改写 §1.3 的因果链：「RoPE 编码不同 → K 向量不同 → block hash 不同」替换为「前文不同 → 哈希链不同 → 查找失败」，并与脚注 [^1] 呼应；
2. 「位置烧进 K」这层保留，但把它的作用挪到「跨位置复用的正确性」上，作为方案 B 的铺垫，避免和 APC 的查找机制混在一处；
3. 追加的讨论段建议并入改写后的正文，行文向正文风格靠拢。