clean up scenario logic in three prescriptive templates

[cafzal]

Summary

• grid_interconnection: Replaced legacy def build_formulation(s) + loop with Scenario concept pattern (single
  solve, all budget scenarios simultaneously). Fixed undefined s parameter bug.
• sprint_scheduling: Added scenario support (was single-solve with hardcoded capacity_multiplier = 1.0). Now loops
  over 3 capacity multiplier values with SCENARIO_PARAM/SCENARIO_VALUES constants.
• demand_planning_temporal: Added full scenario loop over 3 planning horizons (was:
  SCENARIO_PARAM/SCENARIO_VALUES declared but unused, no loop). Fixed multi-arity property types ({production:float}

Two scenario patterns

Both patterns are used, chosen based on the problem structure:

1. Scenario Concept (grid_interconnection) — numeric parameter variations solved in a single p.solve(). Variables
   indexed by Scenario via multi-argument Properties, constraints use .per(Scenario).

2. Loop + where=/parameter (sprint_scheduling, demand_planning, factory_production) — fresh Problem per iteration.
   Used for entity partitioning (where=[]) or when scenario changes the data loaded (e.g., different planning horizons
   filter different demand orders).

Test plan

• grid_interconnection: OPTIMAL, 3 budget scenarios (1B/2B/3B), correct project/upgrade selections per scenario
• sprint_scheduling: OPTIMAL across all 3 capacity_multiplier scenarios (0.5/0.75/1.0), obj=127/123/123
• demand_planning_temporal: Property type fix verified (was TypeError, now compiles)

[github-actions]

The docs preview for this pull request has been deployed to Vercel!

✅ Preview:	https://relationalai-docs-r3nwdf5ir-relationalai.vercel.app/early-access/pyrel/templates
🔍 Inspect:	https://vercel.com/relationalai/relationalai-docs/24Qs3WrGiRfZ9We8oct4ZRCoWj2g

[somacdivad]

Thanks @cafzal! Looks good.