vnext: demand-driven support routing (missingFunctions → providesFunctions → SUPPORT_DEMAND) #61

Context — GPT R7 verdict on PR #60

The R7 review rejected "support capabilities on paper": missions declaring supportCapabilities whose caps are never routed. Lazy support is a dead declaration without a demand mechanism. Current state after the R7 wave: support caps exist with providesFunctions metadata (the substrate), but no mission declares them and nothing routes to them.

What to build

A demand-driven support path so comprehension substrate actually rehearses when learners need it:

1. Evaluator signal: when a target task's evaluation fails, classify the miss — which requiredFunctions were absent (missingFunctions on the evaluation object). Requires the function-checker to distinguish "wrong formulation" from "comprehension gap".
2. Lookup: missingFunctions ∩ support cap providesFunctions → candidate support caps.
3. SUPPORT_DEMAND intent in the planner: mints a probe/practice task for the support cap, scoped to the learner's actual miss — never free-running, never claim-bearing.
4. Probe tasks per support cap (pre-authored, reusable across missions): short discrimination tasks (e.g. number-in-utterance, direction-term spot).
5. Evidence semantics: support evidence is remediation — it helps the retry succeed; it never earns the target cap's milestones and never certifies the support cap independently.
6. Gate additions: support caps may only receive SUPPORT_DEMAND intents; skippedIntents backlog never counts them fatal; providesFunctions must cover a mission task's requiredFunctions to be declared.

Why not now

R7 fixed the immediate dead-declaration by dropping supportCapabilities from missions. The mechanism above is a real subsystem (evaluator + planner + task authoring) and deserves its own PR.

Depends on: #59 (merged). Pairs with: the planner's skipIntentFor machinery already distinguishes intent kinds per capability.