NPU parallelism: multi-instance lanes, column partitions, and QoS priority

[aravishankar-mp]

Follow-on decided during issue #85 (deliberately outside wayfinder map #78). The v1
execution model presents the XDNA NPU as one serial lane per backend instance
(docs/research/amdxdna-execution-model.md §7). The silicon supports more, and a placement
scheduler (kore's manifold) wants multiple schedulable lanes:

1. Validate multi-stream/multi-instance on hardware: the amdxdna driver multiplexes a
   finite pool of hardware contexts, but HRX's userspace has only ever been exercised with
   one stream per process. Prove N instances (each its own stream + worker) dispatch
   concurrently and fail independently.
2. Column-partition targeting: the 8-column array partitions (npu2_1col…npu2_7col
   device variants in the pinned toolchain). Spec how an instance requests a partition and
   what the compiler helper must emit per partition.
3. QoS priority / firmware preemption: the in-tree driver carries per-context priority
   and firmware-gated preemption between contexts (AIE2_PREEMPT, frame-boundary preempt —
   verified in drivers/accel/amdxdna at v7.1). HRX exposes no QoS today; determine the
   honest path (HRX feature request vs driver-level configuration) — never a host knob that
   changes numerics, per ADR-0001's guest-chosen-tier principle (priority is scheduling, not
   numerics, so it may be host policy).
4. Scheduler surface: expose lanes so a heterogeneous scheduler can place by workload
   class (e.g. latency-critical partition at high priority beside a batch partition).

Gated on: map #78's single-lane backend landing first; hardware evidence at each step.