Parametrize PulseTuningProblem on the wrapped problem type

[jack-champagne]

PulseTuningProblem.qcp is annotated with the concrete QuantumControlProblem. Piccolo's typed-templates work (Piccolo.jl#259) turns SamplingProblem from a function returning a QuantumControlProblem into its own wrapper type — SamplingProblem{P,QT} <: AbstractProblemWrapper, and AbstractProblemWrapper <: AbstractQuantumControlProblem. That annotation would reject it, so robust/sampling pulses could no longer be tuned.

Nothing in this repo references SamplingProblem, so no test catches either state today. The regression would be a silent capability loss on the robust-pulse → hardware-tuning path.

Approach

A TunableProblem alias resolved once at load:

const TunableProblem = if isdefined(Piccolo, :AbstractQuantumControlProblem)
    Piccolo.AbstractQuantumControlProblem
else
    Piccolo.QuantumControlProblem
end

…and the problem carried as a third type parameter bound by it (P<:TunableProblem, qcp::P).

Hardcoding either arm breaks one side: concrete QuantumControlProblem rejects the wrapper once it lands, and AbstractQuantumControlProblem is not a name that can be written until then. The alias means this needs no upgrade ordering — it compiles against Piccolo 1.15 through the typed templates, so it can land before, after, or independently of #259, and #259 carries no downstream Intonato break.

Field is now concrete

The old qcp::QuantumControlProblem was a UnionAll (Piccolo already parametrizes it on the trajectory), i.e. an abstract — boxed — field on the struct the tuning loop reads every iteration. Parametrizing makes it concrete:

qcp field type : QuantumControlProblem{KetTrajectory{LinearSplinePulse{…}, …}}
isconcretetype : true

Verification

• Loads and constructs against current Piccolo (1.19); TunableProblem resolves to QuantumControlProblem, field concrete as above.
• Forward arm verified by inspection of #259 rather than execution: AbstractQuantumControlProblem is defined and exported (src/control/problems.jl:52) and AbstractProblemWrapper <: AbstractQuantumControlProblem (:310), so SamplingProblem <: TunableProblem there. Worth re-confirming by dev-pinning once #259 lands.
• No explicit PulseTuningProblem{S,M} instantiations exist outside the definition, so the added parameter breaks no call site.
• Full suite left to CI.