[Feature] Replace static MAX_QUBITS with runtime capacity policy in QDP

[viiccwen]

What

QDP currently treats qubit capacity as a static policy through MAX_QUBITS, with the effective limit described as a fixed 30-qubit / 16GB-style boundary.

That policy is too rigid for the actual execution model:

• available GPU memory is runtime-dependent
• effective capacity depends on precision (float32 vs float64)
• single-state and batch paths do not have the same memory footprint
• future multi-GPU support should not inherit a single static per-process qubit cap

This issue is to replace the static qubit-limit policy with a runtime capacity policy derived from actual execution constraints.

Why

Today, QDP mixes together two different concerns:

• validation policy: whether a requested qubit count should be allowed
• runtime feasibility: whether the requested state / batch can actually fit and run on the current device

That creates several problems:

• a fixed limit is overly conservative on larger GPUs
• it is also too blunt to explain real failures on smaller or fragmented devices
• precision-aware paths cannot express their true capacity cleanly
• later capacity work, including multi-GPU planning, is harder if everything is still routed through one static MAX_QUBITS

A runtime capacity policy would make the system more accurate, more explainable, and easier to extend.

How

Introduce a shared runtime capacity layer that computes whether a request is feasible from inputs such as:

• current device memory / free memory
• state representation precision
• single-state vs batch allocation shape
• encoding path requirements
• optional future sharding / multi-device layout inputs

Suggested scope:

• replace static qubit validation with a shared runtime capacity validator / planner
• return clearer errors that explain requested size vs available capacity
• make validation reusable across:
  • standard encode paths
  • batch encode paths
  • GPU-pointer encode paths
• keep the first implementation scoped to single-device runtime capacity
• leave multi-GPU capacity planning as follow-up work unless the abstraction needs a small hook now

This issue is done when:

• qubit validation no longer depends solely on a fixed static MAX_QUBITS
• capacity decisions are derived from runtime device constraints
• single/batch/precision-specific paths use a shared capacity policy
• errors explain runtime capacity failure more directly than a fixed hardcoded qubit cap

[yehfelareborn]

I would like to contribute to this issue, thanks

[viiccwen]

Sorry, I already took. : (

[yehfelareborn]

ok