fix(dflash): unblock Qwen3.5-MoE + DFlash + ContextPilot serving hang (multi-GPU device placement)

[drunkcoding]

Summary

Fixes the primary open bug in #146: serving the full trifecta —
Qwen3.5-MoE target + DFlash speculative drafter + ContextPilot — via
api_server_v2 reached HEALTHY but token generation hung (client got
HTTP 000, process wedged in the CUDA driver).

Root cause: two independent multi-GPU device-placement bugs in the DFlash
native path. MoE-Infinity keeps the offloaded model's resident backbone
(embed_tokens / attention / lm_head) on the last visible GPU (this is
exactly what ContinuousBatchingEngine._resolve_device does), but the DFlash
speculative path assumed cuda:0:

1. MoE._native_model_forward / _native_model_forward_rich placed the
   input on cuda:0, so the first target forward's embed_tokens(input_ids)
   raised RuntimeError: Expected all tensors to be on the same device (index cuda:0 vs weight cuda:1).
2. DFlashSpeculator._infer_cuda_device returned the first CUDA parameter
   (or cuda:0), so the drafter and its block landed on a different GPU than
   the bound shared embed_tokens/lm_head, failing in _run_drafter's
   self.embed_tokens(block).

Both RuntimeErrors propagated out of engine.step() and were silently
swallowed by the async engine loop, so the request hung indefinitely instead
of returning an error. (This silent-hang-on-step-exception is the mechanism
behind #146 Bug 2 and is why the failure looked like a CUDA wedge rather than a
500.)

Changes

• fix(dflash) — resolve the native-forward input device from the resident
  input embedding (fallback cuda:{last_gpu}), and infer the speculator device
  from the bound shared embedding. Single-GPU / CPU behavior is unchanged
  (last_gpu == 0; CPU path preserved).
• fix(serving) — resolve Qwen3.5-MoE architecture dims via
  config.get_text_config() (its VL config nests text dims under text_config),
  fixing RuntimeError: unable to resolve model num_layers. Text-only configs
  are unaffected (get_text_config() returns self).
• test(contextpilot) — importorskip/skipif guards so the CP suite is
  green with or without the optional contextpilot package (mirrors
  test_tokenizer_compat).

Verification

Live 2×GPU run (CUDA_VISIBLE_DEVICES=0,1) via api_server_v2 with
--speculative-draft z-lab/Qwen3.5-35B-A3B-DFlash --enable-contextpilot:

POST /v1/completions {"prompt":"The capital of France is","max_tokens":16,"temperature":0}
-> HTTP 200 in ~7s: " Paris.\nThe capital of France is Paris. ..."  (16 tokens, 14 verify steps)

• Before: HTTP 000 after 60s (hang). After: generates end-to-end.
• Bisected spec-off (works) vs spec-on (hung) to localize; confirmed the fix on
  clean code.

Regression suites (unchanged from baseline):

• tests/python/dflash — 264 passed, 3 skipped (GPU-gated harnesses)
• tests/python/unit/test_qwen3_5_moe.py — 16 passed
• tests/python/contextpilot — 75 passed, 1 skipped

Notes / out of scope

• Qwen3.5-MoE serving hangs during generation with Dflash + ContextPilot (feat/dflash-tracks-abcd) #146 Bug 2 (engine-loop swallows step exceptions → silent hang) and Bug 3
  (/v1/completions ContextPilot single-prompt list index out of range, caught
  by fallback) are not addressed here; this PR fixes the generation hang
  (Bug 1). Surfacing engine-step exceptions as request errors is a sensible
  follow-up.

Refs: #146