Parametric program compiles to a morphism-less Program; .domain raises an unguided AttributeError (affects shipped gmm example)

[aaronstevenwhite]

Summary

A parametric program (program f(p : T) : A -> B) compiles to a Program whose .morphism is None; accessing .domain / .codomain then raises a bare AttributeError: 'Program' object has no attribute 'domain' with no hint that the program is a parameter template needing instantiation. A shipped gallery example (docs/examples/source/mixture_model.qvr, program gmm(alpha : Real) : Resp -> Resp) trips this.

Repro (quivers 0.13.0)

from quivers.dsl import loads
p = loads("""
object Resp : FinSet 8
program m(alpha : Real) : Resp -> Resp
    sample b <- Normal(0.0, alpha)
    observe y : Resp <- Normal(b, 1.0)
    return y
export m
""")
print(type(p).__name__, p.morphism is None)   # Program True
p.domain

Program True
AttributeError: 'Program' object has no attribute 'domain'

(The non-parametric form program m : Resp -> Resp compiles to a MonadicProgram and works.)

Why it is confusing

1. loads succeeds silently; the failure surfaces much later at .domain / when handing the program to SVI / MCMC.
2. The Program.domain property raises AttributeError("this Program has no exported morphism; ..."), but because it is a @property, Python masks it as 'Program' object has no attribute 'domain', hiding the real reason.
3. There is no documented way in the gallery example to bind alpha and obtain a fittable MonadicProgram.

Expected

At minimum a clear error at loads/access time ("program 'gmm' is parametric in (alpha); bind parameters via <...> before fitting"), a documented instantiation API for parametric programs, and a gallery example (mixture_model.qvr) that actually produces a fittable program.