Make the number of dreaming proposals per run tunable

[jordanrburger]

Idea: Make the number of proposals a dreaming run produces a tunable knob, rather than letting it be emergent/unbounded.

Current behavior

Dreaming proposals are emitted during the feedback-processing mode (phases/modes/feedback-processing.md) and written to dreaming-proposals.md (template: templates/dreaming-proposals.md.tmpl). The amount is governed only by the model's judgment — there is no target or upper bound. The wishlist phase explicitly states "the constraint is quality, not count." A single run can emit anywhere from zero to many proposals. Combined with the opt-out auto-apply model (Pending (auto-apply after <date>), Step 1e), a high volume increases both the user's review burden and the rate of autonomous SKILL.md self-modification.

Why tune it

• Some users want a steady trickle (1–2/run) to keep review light and changes legible; others may want Scout to iterate more aggressively.
• A cap bounds the opt-out auto-apply "firehose" (review burden + governance risk) per run.
• Predictability — knowing roughly how many proposals to expect makes the self-improvement loop easier to reason about.

Sketch (consistent with existing config conventions)

Config lives in scout-config.yaml (template templates/scout-config.yaml.tmpl, shipped defaults engine/scout/defaults/scout-config.yaml, loader engine/scout/config.py), organized into commented sections (plan:, sessions:, thresholds:, off_peak:). Add a dreaming: section, e.g.:

dreaming:
  # Soft target / cap for how many new proposals a single dreaming run writes to
  # dreaming-proposals.md. Lower = lighter review burden + slower self-modification.
  max_proposals_per_run: 3

Then thread the value into the rendered dreaming brain (a template variable or read-from-config step) and have phases/modes/feedback-processing.md respect it when deciding how many proposals to write / auto-apply.

Open questions

• Hard cap vs. soft target — a hard cap risks dropping a high-value proposal; a soft target preserves the "quality, not count" spirit while nudging volume.
• Scope — new-proposals-per-run only, or also the number of opt-out proposals auto-applied per run (Step 1e)?
• Per-run vs. backlog — cap each run's output, or the standing backlog size in dreaming-proposals.md?
• Relationship to enrichment — should a similar knob cover the "🧠 Help me remember" enrichment questions, or stay scoped to SKILL-change proposals?

Not urgent — capturing the idea for later.