Remove experiment log issue creation — consolidate iteration tracking on source issue

[mrjf]

Problem

A single autoloop run currently creates up to 2 additional issues beyond the program's source issue:

1. [Autoloop: {name}] Experiment Log {YYYY}-{MM} — iteration history
2. [Autoloop: {name}] Steering — coordination links (or a fallback issue when protected files prevent pushing)

The experiment log issue is redundant. For issue-based programs, the source issue already receives:

• A status comment (edited each iteration) with best metric, iteration count, and links
• A per-run comment (new comment each iteration) with change description, metric, delta, and commit

The experiment log contains the same information. This is unnecessary issue sprawl.

What to change

All changes are in workflows/autoloop.md:

1. Delete the "Experiment Log Issue" section (lines 746–783) entirely.
2. Remove experiment log references from the iteration loop (Step 5: Accept or Reject):
   - Line 718: Remove 5. Add an entry to the experiment log issue. (accepted path)
   - Line 729: Remove 2. Add a "rejected" entry to the experiment log issue. (rejected path)
   - Line 739: Remove 2. Add an "error" entry to the experiment log issue. (error path)
   - Renumber remaining steps in each path.
3. Remove experiment log references from Cross-Linking (lines 656–663): The three coordinated resources become two: Branch + PR, and State File. Remove mentions of the experiment log issue.
4. Remove experiment log link from the Steering Issue body template (line 804): Remove the - Experiment Log: #{experiment_log_issue_number} line.
5. Remove experiment log link from the Status Comment template (line 848): Remove the | Experiment Log | #{experiment_log_issue_number} | row.
6. Update line 878: Remove "experiment log" from Issue-based programs use the same branching model, state files, experiment log, and steering issue as file-based programs.
7. Consider reducing create-issue max (line 56): From max: 2 to max: 1, since the only issues autoloop should now create are the steering issue or error issues — never both in one run.

What to keep

• The steering issue — it serves as a persistent coordination point.
• The fallback-to-issue behavior when protected files prevent pushing (protected-files: fallback-to-issue on line 47) — the user needs to take manual action on these.
• The per-run comments and status comment on the source issue — these already provide the full iteration history.
• The state file's Iteration History section — this is the machine-readable source of truth.