Incompatible reuse of `MoonEPCommPlan` across different `Buffer` contexts, leading to incorrect routing and layout decisions in expert parallelism.

## Problem

`MoonEPCommPlan` stores routing and layout decisions produced for one Buffer
context, but public plan-consuming methods do not verify that a supplied plan
belongs to that Buffer.

The plan contains:

- `dst` values encoded as `destination_rank * NvS + local_offset`;
- duplicate offsets into rank-local `NvS` storage;
- expert-copy decisions indexed by rank and prefetch slot;
- zero-fill ranges for the planned expert/prefetch layout.

`Buffer.dispatch`, `combine`, `prefetch_weight`, and `reduce_grad` can receive a
plan from another Buffer. Existing checks cover only parts of the required
geometry.

## Concrete combine trigger

```text
Buffer A: R=2, E=4, B=1, S=2, K=1, token_padding=2
N=2, NvS=6, len(plan.dst)=2

Buffer B: R=2, E=4, B=1, S=6, K=1, token_padding=1
N=6, NvS=6
```

The existing combine prologue can accept this pair because `NvS` agrees. The
kernel then uses Buffer B's `N=6` iteration domain while reading Buffer A's
two-entry `dst`. Equal `NvS` therefore does not prove that the plan's iteration
domain is compatible.

A foreign prefetch plan has a second trigger: a plan produced with `E=8` may
contain expert ID 7. Reusing it with an `E=4` Buffer can pass the existing
`experts_to_copy` shape checks when `B` agrees, but the expert ID is outside the
consumer's four-expert tensor.

These are source-derived trigger paths.

## Required invariant

```text
Buffer A --planning--> Plan(marker A, signature A)
|
...