cudaq.sample's feedback rejection is entry-kernel-only: measurement branching inside a called sub-kernel is not rejected

cudaq.sample rejects kernels that branch on measurement results with a clear error steering users to cudaq.run. But the check appears to inspect only the entry-point kernel: the identical feedback inside a called kernel passes the check and samples anyway (with a deprecation warning about named measurement results).

Reproducer (cudaq 0.15.1, PyPI wheels, qpp-cpu):

import cudaq
cudaq.set_target("qpp-cpu")

@cudaq.kernel
def erase_and(q: cudaq.qview):
    h(q[2])
    fired = mz(q[2])
    if fired:
        z.ctrl(q[0], q[1])
        x(q[2])

@cudaq.kernel
def direct_feedback():
    q = cudaq.qvector(2)
    h(q[0])
    fired = mz(q[0])
    if fired:
        x(q[1])

cudaq.sample(direct_feedback, shots_count=10)   # rejected, as documented

@cudaq.kernel
def wrapped_feedback():
    q = cudaq.qvector(3)
    h(q[0]); h(q[1])
    x.ctrl(q[0], q[1], q[2])
    erase_and(q)          # same feedback, one call level down
    mz(q)

cudaq.sample(wrapped_feedback, shots_count=50)  # ACCEPTED, returns counts

Context: the rejection itself is clearly deliberate — the error message steers users to cudaq.run, and cudaq.run handles the same feedback kernel correctly (verified: per-shot results as documented, requiring only that the kernel return a value). So this report is purely about the inconsistent enforcement: the check that redirects users to run is applied to the entry kernel only, and the same feedback one call level down samples anyway.

Expected: the check applied transitively over the call graph, with the same redirect-to-run error in both cases. As is, whether a program is rejected depends on how it is factored into kernels, and code the check was written to exclude runs anyway (with unspecified semantics for the sub-register counts it returns).

Severity: consistency/robustness.

Start by tracing the cudaq.sample feedback-rejection check and compare it with cudaq.run, using the direct_feedback and wrapped_feedback kernels as the reproducer. Verify that the check visits called kernels transitively and that both entry-point and nested measurement feedback produce the documented redirect-to-run error; confirm cudaq.run still handles the feedback kernel correctly.