fix: recompute scheduled tokens after prefix-cache allocation

[tj1235]

This fixes a scheduling bug when prefix cache hits.

Previously, schedule() computed num_tokens before block_manager.allocate(seq).
However, allocate(seq) may increase seq.num_cached_tokens when a prefix block
is reused from cache. This made seq.num_scheduled_tokens stale and could cause
prepare_prefill() to build an invalid [start, end) range, eventually leading
to block_table index overflow.

Fix:

• recompute num_tokens after allocate(seq)
• then set seq.num_scheduled_tokens from the updated cached-token count

Reproduction:

• use repeated-prefix prompts so the first 256-token block can hit prefix cache
• for a 465-token sequence, allocation may set seq.num_cached_tokens = 256
• before this fix, seq.num_scheduled_tokens could still remain 465
• then prepare_prefill() would compute start = 256, end = 721, which exceeds
  the true sequence length and causes out-of-range access on seq.block_table

Validation:

• after this fix, the same case schedules only the uncached suffix tokens
• seq.num_scheduled_tokens becomes 465 - 256 = 209
• prefill range stays valid and no overflow occurs

[GeeeekExplorer]

Thank your advice. We fixed it in newest PR #218