Add bounded Loop and Break structural control flow

[taras]

Motivation

Executable Markdown workflows need visible, bounded repetition for plan review,
structured-output repair, and implementation correction. Loop control must not
hide retry policy inside an agent or provider.

Authoring contract

<Loop name="planning" max={5}>
 <Plan />
 <Review as="verdict" />
 <If condition={verdict.passed}>
 <Break />
 </If>
</Loop>

• <Loop> is a structural built-in, not a filesystem component.
• max is required and must be a positive integer.
• name is optional diagnostic metadata.
• The body expands sequentially up to max times.
• Iterations share the surrounding lexical binding environment.
• Each iteration sees bindings produced by earlier iterations.
• Final bindings remain available after </Loop>.
• Reaching max without <Break> completes normally.
• The surrounding document decides whether exhaustion is success or failure.
• Execution records distinguish normal exhaustion from <Break>, error, and
  cancellation.

Break

• <Break> is self-closing, accepts no props or content, and is valid only
  within an active <Loop>.
• It stops the remainder of the current iteration and exits the nearest active
  loop.
• Bindings and completed effects produced before <Break> remain available.
• Content after <Break> does not expand or create output, bindings, effects,
  imports, or journal entries.
• A nested loop handles its own <Break> without exiting an outer loop.

Iteration identity

The runtime assigns each iteration a deterministic zero-based identity for
journaling and workflow history. The initial component does not expose that
number as an implicit binding or prop. Optional name helps diagnostics but is
not passed to descendants as execution identity.

Testing

Add colocated Loop.test.md and Break.test.md documents without JavaScript.
Together they cover:

• exact repetition through max;
• normal completion after exhaustion;
• immediate <Break>;
• <Break> nested in <If>;
• content after <Break> not executing, using a deliberately failing
  assertion;
• bindings carrying from one iteration to the next;
• final bindings remaining available after the loop;
• nested loops with <Break> exiting only the nearest loop; and
• optional name having no effect on rendered output.

Add lower-level automated tests for:

• missing, zero, negative, fractional, and non-numeric max;
• props or content on <Break>;
• <Break> outside <Loop>;
• errors and cancellation stopping further iterations;
• resource teardown before the loop exits;
• no journal entries from content skipped by <Break>;
• deterministic iteration identities and replay;
• source-positioned diagnostics; and
• behavior across Deno, Node, and Bun.

Documentation

• Specify bounded repetition, binding behavior, exhaustion, nested loops, and
  break semantics in the component reference.
• Add website examples for a fixed loop and a review-until-passed loop.
• Explain that retry-limit failure is explicit document policy rather than
  automatic <Loop> behavior.
• Document that iteration identity is internal in the initial API.

Acceptance criteria

• <Loop max={n}> expands its body at most n times in order.
• Bindings persist across iterations and after the loop.
• Exhaustion completes normally.
• <Break> exits the nearest loop and suppresses all remaining work in
  that iteration.
• Invalid loop bounds and invalid break placement produce clear
  source-positioned errors.
• Execution records distinguish break, exhaustion, failure, and
  cancellation without exposing an iteration binding.
• Markdown tests cover the complete public control-flow contract.
• Lower-level tests cover validation, non-execution, teardown, journaling,
  and replay on the supported runtime matrix.
• Specification and website documentation ship in the same PR.

Not included

• Continue.
• Unbounded loops.
• Automatic failure on exhaustion.
• Author-visible iteration counters.
• Breaking a named outer loop.