Formalize Target backend factory (now) + parameterization framework (deferred north star, post-verification)

[petlenz]

Descoped after an architectural review (see comment below). The original
proposal — a schema()-per-strategy + name-keyed-factory + JSON-pipeline-config
framework reusing numsim-core's param lib — was speculative generality at the
current N (only TWO real strategy points exist, one demoted under graph-coupled),
imported a runtime dependency for cosmetic consistency, and was mis-sequenced
ahead of the verification work that is the named dominant risk. This issue is
now scoped to the one piece with present value; the framework is the deferred
north star.

Do now (cheap, real value)

• Formalize the Target backend factory. Promote the existing 5-line string→Target factory out of examples/recipe_registry_gen.cpp into the library; register the three targets (NumSimMaterialTarget, StandaloneCxxTarget, MooseMaterialTarget); make NumSimMaterialTarget the default. No new dependency, no JSON, no per-strategy schema. ~1 day. This captures ~90% of the practical value of the original "A.2" at ~1% of the cost.

Deferred (north star — do NOT build until the gates below)

The user's stated direction — "the whole chain parameterized + JSON-driven, like numsim-materials; each algorithm a parameterized class" — remains the intended long-term shape. But it should be built demand-pulled, not front-loaded:

• Per-algorithm parameter schemas + a JSON-driven pipeline config.
• The numsim-core (runtime param lib) dependency — reconsider vs. a lightweight local options layer when the time comes; importing the runtime lib into a compile-time tool is a layering cost to justify, not assume.
• "Strategy object over enum" as a rule is dropped — there are no algorithm-selection enums to fix, and the two real strategy points are already polymorphic. Use a polymorphic object when a genuine 2nd/3rd implementation exists (the de-facto practice); don't mandate it for closed sets.
• NewtonOptions stays an injected struct with sane defaults; runtime-tunable convergence is owned by the numsim-materials solver (D17/D14), not duplicated as a codegen-side JSON schema.

Gate the deferred work on:

1. The verification spine (Verification spine: pull numerical-correctness verification (FD tangent + golden model + gates) to the front #90) + a validated golden model land first — the roadmap names "trusting unverified tangents" as the dominant risk (cas#241 as proof); config ergonomics must not precede correctness.
2. A concrete consumer appears — a third FE backend, or an actual external/non-programmer config user (the current C++-recipe model has no such user; a recipe is inherently a programmer artifact).

Not a prerequisite for #92

Corrected: #92 (material-target increments) needs only its PropertySpec/property-contract seam, which is independent of how backend selection is wired. #93 is parallel/optional, not the spine.

Related

#92 (PropertySpec seam — the real near-term emission work), #90 (verification — the actual priority), #17 (user-registered emitters — the open-set extensibility this would eventually serve), #20/#22 (emission substrate), roadmap §2/§5/§6.

[petlenz]

Descoped after an architectural review. Findings: (1) only 2 real strategy points exist (Target, LinearAlgebraEmitter) — a schema+factory+JSON framework is speculative generality at that N; (2) the "strategy over enum" mandate targets a nonexistent problem (no algorithm-selection enums in the tree; the worked example TimeIntegrationScheme evaporated when time integration moved to numsim-materials per D17); (3) importing numsim-core (runtime param lib) into a compile-time tool is a layering cost for cosmetic consistency — codegen and a runtime material share no config artifact; (4) mis-sequenced — the roadmap's own §5/§6 put verification + the property-contract seam first, and name unverified tangents as the dominant risk. Kept the one piece with present value (the Target factory); deferred the framework behind the verification spine (#90) + a real consumer.