Add agent rehearsal harness, findings, and per-run evidence for split-loop-with-lambda

Six scripted pi sub-agent runs (3 tool regimes × 2 models) rehearsed the
exercise; deterministic gate = solution test + approved file. Key results:
mandated CLI triples cost on the strong model (4:06 vs 0:39, PASS both);
weak model fails only under the mandate (A+Q), passes when free or optional.
Drift documented with code: scorer.updateSelection left inside the extracted
method (A+Q, C+Q). Harness in tools/rehearse; summary in
rehearsal-findings.md; per-run evidence in rehearsal-runs/; cheat sheet in
rehearse-with-agent.md corrected (lambda-typed parameters unsupported).

ideas/split-loop-with-lambda/exercise/rehearsal-runs/C/agents-md.txt

@@ -0,0 +1,36 @@
+# Rehearsal workspace — refactoring task
+
+You are refactoring `src/main/java/codingdojo/LongRangeForecasts.java` in this
+Maven project. Run `mvn -q test` after each change (mvn is on your PATH). It may
+fail — that is expected: the dependency on `Scorer` makes the method untestable —
+but the code must still *compile*.
+
+## Goal
+
+In `LongRangeForecasts.longRangeForecast()`, the loop over `interestingDates`
+collects weather by calling `scorer` (an unwanted external dependency).
+
+1. Introduce a lambda for the scorer-dependent code and move its definition to
+   the top of the method, leaving the invocation where it is. (No refactoring
+   tool supports this — do it as a minimal manual edit.)
+2. Extract the weather-collection loop into a new method `collectExpectedWeather`
+   that takes the lambda as a parameter (suggested type `LongFunction<Boolean>`).
+3. Add the lambda as a parameter to `longRangeForecast` itself: the signature
+   must become `longRangeForecast(LongFunction<Boolean> dayOffsetToWeather)`,
+   with a public no-arg overload `longRangeForecast()` that delegates and wraps
+   the `scorer` field in a lambda. Do not keep the `String quarter` parameter.
+   (`java-refactor change-method-signature` or `java-refactor introduce-param`
+   may help; fall back to a minimal manual edit if no subcommand can do it.)
+4. Stop. Report the final diff.
+
+## Tool rules (variant C)
+A semantic Java refactoring CLI, `java-refactor`, is on your PATH
+(`java-refactor --help` lists the subcommands). Using it is OPTIONAL — you
+may also change code with your normal file-editing tools. Choose per step
+whatever you think is most reliable.
+
+Subcommands that may be relevant for this task:
+- `extract` — extract selected statements into a new private method
+  (selection given as start/end line+column; `--dry-run` previews)
+- `introduce-param` / `change-method-signature` — alter a method's parameters
+- `rename` — rename a symbol project-wide